Java虛擬機器：JVM記憶體分代策略
Java虛擬機器根據物件存活的週期不同，把堆記憶體劃分為幾塊，一般分為新生代、老年代和永久代（對HotSpot虛擬機器而言），這就是JVM的記憶體分代策略。
為什麼要分代？
堆記憶體是虛擬機器管理的記憶體中最大的一塊，也是垃圾回收最頻繁的一塊區域，我們程式所有的物件例項都存放在堆記憶體中。給堆記憶體分代是為了提高物件記憶體分配和垃圾回收的效率。試想一下，如果堆記憶體沒有區域劃分，所有的新建立的物件和生命週期很長的物件放在一起，隨著程式的執行，堆記憶體需要頻繁進行垃圾收集，而每次回收都要遍歷所有的物件，遍歷這些物件所花費的時間代價是巨大的，會嚴重影響我們的GC效率，這簡直太可怕了。
有了記憶體分代，情況就不同了，新建立的物件會在新生代中分配記憶體，經過多次回收仍然存活下來的物件存放在老年代中，靜態屬性、類資訊等存放在永久代中，新生代中的物件存活時間短，只需要在新生代區域中頻繁進行GC，老年代中物件生命週期長，記憶體回收的頻率相對較低，不需要頻繁進行回收，永久代中回收效果太差，一般不進行垃圾回收，還可以根據不同年代的特點採用合適的垃圾收集演算法。分代收集大大提升了收集效率，這些都是記憶體分代帶來的好處。
記憶體分代劃分
Java虛擬機器將堆記憶體劃分為新生代、老年代和永久代，永久代是HotSpot虛擬機器特有的概念，它採用永久代的方式來實現方法區，其他的虛擬機器實現沒有這一概念，而且HotSpot也有取消永久代的趨勢，在JDK 1.7中HotSpot已經開始了“去永久化”，把原本放在永久代的字串常量池移出。永久代主要存放常量、類資訊、靜態變數等資料，與垃圾回收關係不大，新生代和老年代是垃圾回收的主要區域。記憶體分代示意圖如下：
新生代（Young）
新生成的物件優先存放在新生代中，新生代物件朝生夕死，存活率很低，在新生代中，常規應用進行一次垃圾收集一般可以回收70% ~ 95% 的空間，回收效率很高。
HotSpot將新生代劃分為三塊，一塊較大的Eden空間和兩塊較小的Survivor空間，預設比例為8：1：1。劃分的目的是因為HotSpot採用複製演算法來回收新生代，設定這個比例是為了充分利用記憶體空間，減少浪費。新生成的物件在Eden區分配（大物件除外，大物件直接進入老年代），當Eden區沒有足夠的空間進行分配時，虛擬機器將發起一次Minor GC。
GC開始時，物件只會存在於Eden區和From Survivor區，To Survivor區是空的（作為保留區域）。GC進行時，Eden區中所有存活的物件都會被複制到To Survivor區，而在From Survivor區中，仍存活的物件會根據它們的年齡值決定去向，年齡值達到年齡閥值（預設為15，新生代中的物件每熬過一輪垃圾回收，年齡值就加1，GC分代年齡儲存在物件的header中）的物件會被移到老年代中，沒有達到閥值的物件會被複制到To Survivor區。接著清空Eden區和From Survivor區，新生代中存活的物件都在To Survivor區。接著， From Survivor區和To Survivor區會交換它們的角色，也就是新的To Survivor區就是上次GC清空的From Survivor區，新的From Survivor區就是上次GC的To Survivor區，總之，不管怎樣都會保證To Survivor區在一輪GC後是空的。GC時當To Survivor區沒有足夠的空間存放上一次新生代收集下來的存活物件時，需要依賴老年代進行分配擔保，將這些物件存放在老年代中。
老年代（Old）
在新生代中經歷了多次（具體看虛擬機器配置的閥值）GC後仍然存活下來的物件會進入老年代中。老年代中的物件生命週期較長，存活率比較高，在老年代中進行GC的頻率相對而言較低，而且回收的速度也比較慢。
永久代（Permanent）
永久代儲存類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料，對這一區域而言，Java虛擬機器規範指出可以不進行垃圾收集，一般而言不會進行垃圾回收。
Minor GC 和 Full GC的區別
新生代GC（Minor GC）：Minor GC指發生在新生代的GC，因為新生代的Java物件大多都是朝生夕死，所以Minor GC非常頻繁，一般回收速度也比較快。當Eden空間不足以為物件分配記憶體時，會觸發Minor GC。
老年代GC（Full GC/Major GC）：Full GC指發生在老年代的GC，出現了Full GC一般會伴隨著至少一次的Minor GC（老年代的物件大部分是Minor GC過程中從新生代進入老年代），比如：分配擔保失敗。Full GC的速度一般會比Minor GC慢10倍以上。當老年代記憶體不足或者顯式呼叫System.gc()方法時，會觸發Full GC。