最近在看周志明老師的《深入理解 Java 虛擬機》一書，收獲頗多，以下為看完前半部分后的一些算是讀書筆記吧，結合書本內容，簡單記錄分享一下有關 JVM 內存分代以及垃圾回收相關的內容。

[[189490]]

JVM 內存區(qū)域

都知道 JVM 的內存區(qū)域分為5個部分，如果有疑惑，可以參看之前的一篇文章 -JVM 內存區(qū)域介紹。

這里也簡單羅列一下 JVM 的五部分

程序計數器

這是一塊較小的內存空間，它的作用可以看做是當前線程所執(zhí)行的字節(jié)碼的行號指示器，線程私有。

Java 虛擬機棧

它是 Java方法執(zhí)行的內存模型，每一個方法被調用到執(zhí)行完成的過程，就對應著一個棧幀在虛擬機棧中從入棧到出棧的過程，線程私有。

本地方法棧

跟虛擬機棧類似，不過本地方法棧用于執(zhí)行本地方法，線程私有。

Java 堆

該區(qū)域存在的唯一目的就是存放對象，幾乎應用中所有的對象實例都在這里分配內存，所有線程共享。

方法區(qū)

它用于存儲已被虛擬機加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數據，所有線程共享。

有關 OOM

都知道，任何一個應用在啟動后，操作系統(tǒng)分配給它的內存一定是有限的，所以如何合理有效的管理內存，就變得尤為重要。

而從上節(jié)可知，我們一般討論的對象內存分配均發(fā)生在 Java 堆上。所以這里說的內存管理大部分情況下即指對 Java 堆內存。而程序計數器、虛擬機棧他們隨著線程生而生，亡而亡，所以他們內存相對比較好管理，出現的問題也比較少。

一個應用啟動后，不停運行，不停的執(zhí)行命令，創(chuàng)建對象，而這些對象，大都存放在堆內存區(qū)域。這部分區(qū)域的大小是有限的，而需要生成的對象是無限的，當某一次創(chuàng)建對象時發(fā)現堆內存實在沒有空間可用來創(chuàng)建對象的時候，JVM 就會爆出 OutOfMemoryError 異常(后文統(tǒng)稱 OOM)，程序就會掛掉。

上面只是說明了一下表象。其實 OOM 遠不是上面說的那么簡單。如果要理解 OOM，這里還有一些其他知識需要說明。

• OOM 發(fā)生前其實 JVM 會進行內存的垃圾回收(GC)。
• 垃圾回收有多種不同的實現算法。
• 為了更好的管理內存，堆內存進行了分代。
• 堆內存的新生代和老年代的垃圾回收算法不一致。

其實，這里的知識需要綜合理解，你才會對 OOM 有一個全面的認識。

內存分代

一個應用啟動，操作系統(tǒng)會給他分配一個初始的內存大小，由上可知，這部分內存大部分應該屬于堆內存，JVM 為了更好地利用管理這部分內存，對該區(qū)域做了劃分。一部分成為新生代，另一部分稱為老年代。

一開始對象的創(chuàng)建都發(fā)生在新生代，隨著對象的不斷創(chuàng)建，如果新生代沒有空間創(chuàng)建新對象，將會發(fā)生 GC ，這時的 GC 稱之為 Minor GC，位于新生代的對象每經過一次 Minor GC 后，如果這個對象沒有被回收，則為自己的標記數加1，這個標記數用于標識這個對象經歷了多少次的 Minor GC，對于 Sun 的 Hotspot 虛擬機，如果這個次數超過 15 ，該對象才會被移動到老年代。

隨著時間的推移，如果老年代也沒有足夠的空間容納對象，老年代也會試著發(fā)起 GC，這時的 GC 被稱為 Full GC。

相比 Minor GC，Full GC 發(fā)生的次數比較少，但是每發(fā)生一次 Full GC，整個堆內存區(qū)域都需要執(zhí)行一次垃圾回收，這對程序性能造成的影響比 Minor GC 大很多。所以我們應該盡量避免或者減少 Full GC 的發(fā)生。

同時，在堆內存區(qū)域，發(fā)生最多的 GC 情形就是新生代的 Minor GC 了，因為所有的對象會優(yōu)先去新生代開辟空間，所以這塊的內存變化會很快，只有內存不夠用，就會發(fā)生 GC，但是一般的 Minor GC 執(zhí)行比 Full GC 快很多。為什么呢?因為新生代和老年代的垃圾回收算法不一樣。

垃圾回收算法

標記-清除算法(Mark-Sweep)

這是最基礎的收集算法，如它的名字一樣，算法分為“標記”和“清除”兩個階段：

首先標記出所有需要回收的對象，在標記完成后統(tǒng)一回收掉所有被標記的對象。

之所以說它是最基礎的收集算法，是因為后續(xù)的收集算法都是基于這種思路并對其缺點進行改進而得到的。

它的主要缺點有兩個：一個是效率問題，標記和清除過程的效率都不高;另外一個是空間問題，標記清除之后會產生大量不連續(xù)的內存碎片，空間碎片太多可能會導致，當程序在以后的運行過程中需要分配較大對象時無法找到足夠的連續(xù)內存而不得不提前觸發(fā)另一次垃圾收集動作。

復制算法(Copying)

為了解決效率問題，一種稱為“復制”(Copying)的收集算法出現了，它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活著的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。

這樣使得每次都是對其中的一塊進行內存回收，內存分配時也就不用考慮內存碎片等復雜情況，只要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效。只是這種算法的代價是將內存縮小為原來的一半，未免太高了一點。

但是這種算法的效率相當高，所以，現在的商業(yè)虛擬機都采用這種收集算法來回收新生代。為什么新生代可以使用復制算法呢?

IBM 有專門研究表明，新生代中的對象 98% 都是朝生夕死，所以就不需要按照1:1的比例來劃分內存空間。這里鑒于此，新生代采用了如下的劃分策略。

現在把新生代再劃分為三部分，一塊較大的 Eden(伊甸園) 和兩塊較小的 Survivor(幸存者) 區(qū)域。

當回收時，將 Eden 和 Survivor 中還存活著的對象一次性地拷貝到另外一塊Survivor空間上，最后清理掉Eden和剛才用過的Survivor的空間。HotSpot 虛擬機默認Eden和Survivor的大小比例是8∶1，也就是每次新生代中可用內存空間為整個新生代容量的90%(80%+10%)，只有10%的內存是會被“浪費”的。

這樣清理完成后，原來的 Survivor 就空了，并一直保持為空，直到下次 Minor GC 時，它再作為存活對象的盛放地。兩個 Survivor 就這樣輪流當做 GC 過程中新生代存活對象的中轉站。

但是，如果使用復制算法的內存區(qū)域有大量的存活對象時，復制算法就會變得捉襟見肘，這時需要更大的 Survivor 區(qū)用于盛放那些存活對象，甚至可能需要 1:1的比例。所以針對堆內存區(qū)域的老年代，就有了下面的算法。

標記-整理算法

標記過程仍然與“標記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進行清理，而是 讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內存 。這種方法避免了碎片的產生，同時也不需要一塊額外的內存空間，對于老年代會比較合適。

但是相比復制算法，雖然該算法占用的內存空間少，但是耗費的垃圾回收時間會比復制算法久，所以上面也說了

• 我們應該盡量避免或者減少 Full GC 的發(fā)生。
• 這兩種算法用精煉的語言描述就是
• 復制算法:用空間換時間
• 標記-整理算法：用時間換空間

一句話 魚與熊掌不可兼得，但是針對新生代和老年代，他們都是最佳的選擇。

總結

簡單梳理一下文中講到的一些知識點

• 為了更好的管理堆內存，該區(qū)域分為新生代和老年代。
• 新生代發(fā)生垃圾回收要比老年代頻繁。
• 新生代發(fā)生的垃圾回收成為 Minor GC;老年代發(fā)生的 GC 成為 Full GC。
• 為了更高效管理新生代的內存，按照復制算法，結合 IBM 的研究論證，新生代分為三塊，一塊比較大的 Eden 區(qū)和兩塊比較小的 Survivor 區(qū)，比例為 8:1:1

參考

《深入理解 Java 虛擬機》- 周志明老師