莊周夢蝶

    Java的垃圾收集算法是分代的，因為根據2/8原則，80%的Java對象都是速生速滅的，因此將Java Heap劃分為new和old，對兩個區域采用不同的垃圾回收算法，在new代存活下來的對象轉移到old區，這樣一來大大提高了Java GC的效率。
    類似分代的思想在很多地方可以用到，分代的本質是根據對象生命周期的不同做區別處理，而不是采取一刀切的方式來提高系統的處理效率。推而廣之，比如緩存的使用，現在很多web應用都采用了類似memcached這樣的緩存擋在數據庫前面分擔負載，那么你可以將memcached理解成new代，而數據庫是old代。memcached中存儲的是查詢的熱點數據，新鮮火熱，但是易失，并且在數據更新的時候被移除；而數據庫保存了所有的數據，當緩存沒有命中的時候才去查詢數據庫并存儲到緩存。new和old這只是簡單的二代劃分，事實上現在越來越多的系統是多級緩存，頁面緩存、memcached緩存、JVM內部緩存、查詢緩存等等直到數據庫，從web頁面到后端是一個越來越old的過程，緩存對象持續的生命周期逐漸增長直到persist狀態。
    具體到JVM內部緩存，我們通常使用LRU算法來實現一個安全有限的緩存，如直接繼承LinkedHashMap將可以實現一個簡單的LRUMap。基于內存使用上的考慮，我們會給LRUMap設定一個最大的capacity，當數據量超過這個capacity的時候將最近最少訪問的元素移除來容納新的元素。這樣處理產生的問題是這個capactity不能設置得太大，因為怕內存不夠用，但是不夠大的結果可能是命中率沒有那么高（跟你的場景相關），那么如何在保存內存安全的前提下更進一步緩存更多的對象呢？答案也是分代。LRUMap默認存儲的都是對象的強引用，我們知道Java還有其他3種引用類：soft,weak和phantom。其中Soft引用是在jvm內存不夠的時候進行回收，weak引用是在垃圾回收碰到的時候會被回收，顯然weak->soft->strong三類引用的生命周期可以劃分為3個代，我們將可以實現一個可以容納更多對象的LRUMap：LRUMap設置兩個閥值，一個是強引用的最大閥值，這個不能太大，一個是軟引用的最大數目，當超過第一個閥值的時候，不是將LRU替換出來的對象移除，而是替代轉換為軟引用存儲；如果軟引用的數目也超過閥值，那么可以將軟引用這個Map里的對象LRU替換成Weak引用存儲或者簡單移除。處理元素查詢的時候，多了一個步驟，在查詢強引用未果的情況下，需要再去查詢軟引用集合，不過都是O(1)復雜度的查詢，不會成為明顯的瓶頸。通過將緩存對象分代，我們實現了容難更多緩存對象的目標，大部分對象以強引用的形式存儲，被LRU替換出去最近最少訪問的元素以軟引用存儲，它們在內存不夠的時候被垃圾回收，保證了內存使用上的安全性。我們在系統中采用了類似這樣的緩存，緩存的命中率有了明顯的提高。
    題目是《緩存的分代》，其實談的是分代這種常見的設計或者說技巧，在需要處理大量對象的場景中，不采用一刀切的方式，而是根據對象的特點進行適當的分代處理，帶來的效率提升可能是驚人的。

    PS.關于這個招聘羅嗦兩句，我是這個小組的成員，有人質疑我的目的是為了賺推薦費，這個不能說沒有，不過主要目的還是招人，我們很缺人。那么多要求可以歸結為一句話：我們找Java基礎良好、對并發通信有豐富實踐經驗、寫代碼相對靠譜、為人相對靠譜的人。那些要求并非硬性，如果你覺的合適，盡管投簡歷，謝謝。我們小組做的東西我認為還是有價值的，也很有挑戰，淘寶內部的很多應用都在使用，如果你希望你做的產品被成千上萬的人每天使用，歡迎加入。