譯文-java垃圾回收機制

原文出處：java垃圾回收機制

標記清除算法介紹最主要的理論算法之一，在實踐過程當中，爲了真實情景須要，須要許多調整。舉一個簡單例子，咱們檢查JVM須要作的各類事情，以便咱們安全地去建立對象。

清除壓縮

當清除期間，JVM必須確保區域被不可達對象填充。這會(終將會)致使內存碎片化，一樣會致使磁盤碎片化，由此產生兩個問題：

• 寫操做由於尋找下一個足夠尺寸的空間變得耗費時間，這個寫操做再也不簡單。

• 當建立新對象的時候，JVM分配一個連續的空間。若是內存碎片遍及每個點，沒有足夠的空間容納新建立的對象，分配就會發生錯誤。

爲了不上面的問題，JVM會確保碎片化不會失控。所以不會僅僅標記清除，垃圾回收期間，"內存整理"進程同時在工做。這個進程從新分配全部的可達對象讓他們緊密排列，消除（或者減小）碎片。下面是示意圖：

分代假設

正如咱們以前提到，垃圾收集會引發應用完全停頓。對象越多回收垃圾花費的時間越長，這是顯而易見的。若是咱們把使用一小塊內存工做變成可能，那又會怎樣呢？爲了研究這種可行性，一些專家發現應用的大多數內存分爲如下兩種狀況：

• 絕大多數對象很快就成爲無用對象。

• 不多部分對象講過很長時間存活下來。

上面的觀察結果歸類於新生代假設。基於這個假設：VM內存空間被劃分爲Young代 和Old代，後者有時也叫作Tenured。

衆多算法在提高GC性能上已經取得進展，使得擁有這樣一個獨立易清除的內存區域變成現實。

這種方式雖然說不上毫無問題。當垃圾收集器收集一個分代中的對象的時候，不一樣分代中的對象彼此相互引用的時，實際上被看成"GC roots"。

可是更更要的一點是，分代假設並不適用於一些應用。自此，由於那些「夭折」和「有可能永生」的對象,GC算法作了優化，JVM對那些期待更久生命的對象表現得友好。

內存空間

讀者應該瞭解下圖中java堆區裏面的內存劃分。不一樣內存區域的垃圾收集機制不辣麼容易理解。應該注意，不一樣GC算法實現細節可能不一樣，然而它們的理念是一致的。

Eden

Eden區是對象被新建立的時候分配的內存區域。在這個區域中，多線程能夠同時建立多個對象。在Eden區裏，Eden 被分紅一個或多個Thread Local Allocation Buffer (縮寫：TLAB)。在這些緩存裏，JVM容許線程在對應的緩存中分配絕大多數的對象，避免昂貴的多線程同步。

當TLAB中不能分配空間時（由於空間不足），JVM會移到共享的Eden區去分配，若是共享Eden空間也不足時，Young代中垃圾回收器去釋放更多的空間。若是在GC以後尚未足夠的空間以供使用，對象會在Old代中分配。

當Eden回收期間，GC把全部的可達對象標記爲存活。

咱們已經提早注意到，對象能夠跨代關聯，所以咱們必須有一個快捷途徑去檢查其餘代的對象引用Eden區中的對象。

從一開始就記錄全部的分代引用是不可取的， JVM有本身的機制：卡標記。事實上，JVM僅僅標記Eden裏面有可能Old代引用Eden代的對象的「髒」對象的位置，你能夠在Nitsan的博客裏瞭解更多的信息。

標記階段完成以後，Eden區下面全部存活的對象被複制到Survivor下面的一塊區域中。如今，Eden區被清空，從新分配新建對象。正如「標記-複製」的名稱同樣：存活的對象被標記，而後複製(不是移動)到Survivor區。

Survivor區

緊鄰Eden區的下一個區域時兩個叫作from和to的Survivor區。須要注意的一點，兩塊區域中的一塊是空的。

Survivor中的空的區域會保存下一刻Young代中垃圾回收後的對象。Young代全部存活的對象（包括Eden區和Survior區中非空的from區域）被複制到Survivor區的"to"區域。在這以後，「to」區域存放全部對象，「from」區域清空。二者進行調換（譯者注：即from變成to,to變成from）。

在兩個區域進行數次複製存活對象操做，直到一些對象足夠成熟（「old enough」）。記住這一點，基於分代假設，一些對象在數次GC以後存活下來，並且在很長一段時間內繼續被引用。

這樣的「tenured」對象會升級到Old代。這種狀況發生的時候，對象再也不從Survuvor區一個區域移動到另一個區域，而是進入Old區，在成爲不可達對象以前它們一直存在在old區中。

爲了肯定哪些對象「old enough」,須要爲old區提供一種算法，GC記錄倖存對象的詳細信息。每代GC完成以後，那些依然存活的對象年齡進行增加。每當年齡超過設定的閥值以後，對象纔會被升遷到old區。

實際上閥值被JVM動態設定，-XX:+MaxTenuringThreshold 除外，它設置最高限定。XX:+MaxTenuringThreshold=0 表示跳過Survivor區的兩個區域之間複製過程直接進入old區。jvm默認閥值是GC循環15次。在Hotspot是最大值。

Survivor區空間不足以容納Young代全部存活對象的時候升遷操做被提早觸發。

Old代

Old代的具體實現細節巨複雜。Old代一般被那些幾乎不可能被看成垃圾的對象佔據。

Old代GC觸發的次數比Young代少。所以，Old代中的存活對象，不會發生標記複製過程。相反，這些對象保持最小碎片化。這種算法創建在不一樣維度之上。大致上，分爲如下幾步：

• 經過設置全部GC roots可達的對象標記位來標記全部可達對象。

• 刪除全部的不可達對象。

• 經過複製對象並緊密排列在Old區的頂端壓縮Old區的空間。

正如你看到上面描述的那樣，Old代的GC必須明確處理壓縮錯左避免過多的碎片。

PermGen

JAVA 8以前中被稱做「Permanent Generation」的特殊區域。這是之前存放例如class的metadata。而，Permgen還存儲String之類的額外數據。實際上爲JAVA開發者添加了許多麻煩，由於很難預測到底須要多少的空間。這些錯誤的預測結果表現形式爲java.lang.OutOfMemoryError: Permgen space。除非是相似OutOfMemoryError的緣由是真的是由於內存泄漏，解決這種問題的簡單方法是增長permgen尺寸。下圖中設置permgen尺寸的最大值爲256M：

java -XX:MaxPermSize=256m

Metaspace

正如預測metadata是一件紛繁複雜的事情那樣，JAVA 8移除了Permanent區，換做Metaspace。從那時起，絕大多數複雜的事情都被移到Java heap區。

類定義文件，如今都存入叫作「Metaspace」的區域中。他至關於本地內存的一塊區域。理論上，Metaspace尺寸僅僅受限於JAVA進程可得到本地內存大小。將JAVA開發人員從僅僅在應用多增長一個類就形成java.lang.OutOfMemoryError: Permgen space的困境中解脫出來。須要注意的是這個看起來不受限制沒有損失的空間-讓Metaspace無限制的增加你會引發內存重交換或者/和本地內存分配失敗。

某些場合你但願保護本身，你能夠以下圖所示限制Metaspace增加，Metaspace尺寸限制在265M：

java -XX:MaxMetaspaceSize=256m