jvm系列(三):GC算法垃圾收集器

作者：純潔的微笑 2017-09-21 14:40:06

垃圾收集 Garbage Collection 通常被稱為“GC”，它誕生于1960年 MIT 的 Lisp 語言，經過半個多世紀，目前已經十分成熟了。

[[204469]]

概述

垃圾收集 Garbage Collection 通常被稱為“GC”，它誕生于1960年 MIT 的 Lisp 語言，經過半個多世紀，目前已經十分成熟了。 jvm 中，程序計數器、虛擬機棧、本地方法棧都是隨線程而生隨線程而滅，棧幀隨著方法的進入和退出做入棧和出棧操作，實現了自動的內存清理，因此，我們的內存垃圾回收主要集中于 java 堆和方法區中，在程序運行期間，這部分內存的分配和使用都是動態的.

對象存活判斷

判斷對象是否存活一般有兩種方式：

引用計數：每個對象有一個引用計數屬性，新增一個引用時計數加1，引用釋放時計數減1，計數為0時可以回收。此方法簡單，無法解決對象相互循環引用的問題。

可達性分析(Reachability Analysis)：從GC Roots開始向下搜索，搜索所走過的路徑稱為引用鏈。當一個對象到GC Roots沒有任何引用鏈相連時，則證明此對象是不可用的。不可達對象。

在Java語言中，GC Roots包括：

虛擬機棧中引用的對象。
方法區中類靜態屬性實體引用的對象。
方法區中常量引用的對象。
本地方法棧中JNI引用的對象。

垃圾收集算法

標記 -清除算法

“標記-清除”(Mark-Sweep)算法，如它的名字一樣，算法分為“標記”和“清除”兩個階段：首先標記出所有需要回收的對象，在標記完成后統一回收掉所有被標記的對象。之所以說它是最基礎的收集算法，是因為后續的收集算法都是基于這種思路并對其缺點進行改進而得到的。

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

復制算法

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

這樣使得每次都是對其中的一塊進行內存回收，內存分配時也就不用考慮內存碎片等復雜情況，只要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效。只是這種算法的代價是將內存縮小為原來的一半，持續復制長生存期的對象則導致效率降低。

標記-壓縮算法

復制收集算法在對象存活率較高時就要執行較多的復制操作，效率將會變低。更關鍵的是，如果不想浪費50%的空間，就需要有額外的空間進行分配擔保，以應對被使用的內存中所有對象都100%存活的極端情況，所以在老年代一般不能直接選用這種算法。

根據老年代的特點，有人提出了另外一種“標記-整理”(Mark-Compact)算法，標記過程仍然與“標記-清除”算法一樣，但后續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內存

分代收集算法

GC分代的基本假設：絕大部分對象的生命周期都非常短暫，存活時間短。

“分代收集”(Generational Collection)算法，把Java堆分為新生代和老年代，這樣就可以根據各個年代的特點采用最適當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用“標記-清理”或“標記-整理”算法來進行回收。

垃圾收集器

如果說收集算法是內存回收的方法論，垃圾收集器就是內存回收的具體實現

Serial收集器

串行收集器是最古老，最穩定以及效率高的收集器，可能會產生較長的停頓，只使用一個線程去回收。新生代、老年代使用串行回收;新生代復制算法、老年代標記-壓縮;垃圾收集的過程中會Stop The World(服務暫停)

參數控制： -XX:+UseSerialGC 串行收集器

ParNew收集器 ParNew收集器其實就是Serial收集器的多線程版本。新生代并行，老年代串行;新生代復制算法、老年代標記-壓縮

參數控制：

-XX:+UseParNewGC ParNew收集器

-XX:ParallelGCThreads 限制線程數量

Parallel收集器

Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量。可以通過參數來打開自適應調節策略，虛擬機會根據當前系統的運行情況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或***的吞吐量;也可以通過參數控制GC的時間不大于多少毫秒或者比例;新生代復制算法、老年代標記-壓縮

參數控制： -XX:+UseParallelGC 使用Parallel收集器+ 老年代串行

Parallel Old 收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法。這個收集器是在JDK 1.6中才開始提供

參數控制： -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一種以獲取最短回收停頓時間為目標的收集器。目前很大一部分的Java應用都集中在互聯網站或B/S系統的服務端上，這類應用尤其重視服務的響應速度，希望系統停頓時間最短，以給用戶帶來較好的體驗。

從名字(包含“Mark Sweep”)上就可以看出CMS收集器是基于“標記-清除”算法實現的，它的運作過程相對于前面幾種收集器來說要更復雜一些，整個過程分為4個步驟，包括：

初始標記(CMS initial mark)
并發標記(CMS concurrent mark)
重新標記(CMS remark)
并發清除(CMS concurrent sweep)

其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的對象，速度很快，并發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正并發標記期間，因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比并發標記的時間短。

由于整個過程中耗時最長的并發標記和并發清除過程中，收集器線程都可以與用戶線程一起工作，所以總體上來說，CMS收集器的內存回收過程是與用戶線程一起并發地執行。老年代收集器(新生代使用ParNew)

優點: 并發收集、低停頓

缺點: 產生大量空間碎片、并發階段會降低吞吐量

參數控制：

-XX:+UseConcMarkSweepGC 使用CMS收集器

-XX:+ UseCMSCompactAtFullCollection Full GC后，進行一次碎片整理;整理過程是獨占的，會引起停頓時間變長

-XX:+CMSFullGCsBeforeCompaction 設置進行幾次Full GC后，進行一次碎片整理

-XX:ParallelCMSThreads 設定CMS的線程數量(一般情況約等于可用CPU數量)

G1收集器

G1是目前技術發展的最前沿成果之一，HotSpot開發團隊賦予它的使命是未來可以替換掉JDK1.5中發布的CMS收集器。與CMS收集器相比G1收集器有以下特點：

空間整合，G1收集器采用標記整理算法，不會產生內存空間碎片。分配大對象時不會因為無法找到連續空間而提前觸發下一次GC。

可預測停頓，這是G1的另一大優勢，降低停頓時間是G1和CMS的共同關注點，但G1除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為N毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已經是實時Java(RTSJ)的垃圾收集器的特征了。

上面提到的垃圾收集器，收集的范圍都是整個新生代或者老年代，而G1不再是這樣。使用G1收集器時，Java堆的內存布局與其他收集器有很大差別，它將整個Java堆劃分為多個大小相等的獨立區域(Region)，雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔閡了，它們都是一部分(可以不連續)Region的集合。