JVM的GC垃圾收集器
目錄- 一、概述
- 二、垃圾收集器(garbage collector (GC)) 是什麼？
- 三、為什麼需要GC？
- 四、為什麼需要多種GC？
- 五、對象存活的判斷
- 六、垃圾回收算法
- 6.1 标記 -清除算法
- 6.2 複制算法
- 6.3 标記-整理算法
- 6.4 分代收集算法
- 七、垃圾收集器
- 7.1 Serial收集器
- 7.2 ParNew收集器
- 7.3 Parallel收集器
- 7.4 CMS收集器
- 7.5 G1收集器
- 八、常用的收集器組合
回到頂部
一、概述
垃圾收集 Garbage Collection 通常被稱為“GC”，它誕生于1960年 MIT 的 Lisp 語言，經過半個多世紀，目前已經十分成熟了。
jvm 中，程式計數器、虛拟機棧、本地方法棧都是随線程而生随線程而滅，棧幀随着方法的進入和退出做入棧和出棧操作，實作了自動的記憶體清理，是以，我們的記憶體垃圾回收主要集中于 java 堆和方法區中，在程式運作期間，這部分記憶體的配置設定和使用都是動态的。
回到頂部
二、垃圾收集器(garbage collector (GC)) 是什麼？
GC其實是一種自動的記憶體管理工具，其行為主要包括2步
- 在Java堆中，為新建立的對象配置設定空間
- 在Java堆中，回收沒用的對象占用的空間
回到頂部
三、為什麼需要GC？
釋放開發人員的生産力
回到頂部
四、為什麼需要多種GC？
首先，Java平台被部署在各種各樣的硬體資源上，其次，在Java平台上部署和運作着各種各樣的應用，并且使用者對不同的應用的 性能名額 (吞吐率和延遲) 預期也不同，為了滿足不同應用的對記憶體管理的不同需求，JVM提供了多種GC以供選擇
性能名額
最大停頓時長：垃圾回收導緻的應用停頓時間的最大值
吞吐率：垃圾回收停頓時長和應用運作總時長的比例
不同的GC能滿足不同應用不同的性能需求，現有的GC包括：
-
- 序列化GC(serial garbage collector)：适合占用記憶體少的應用
- 并行GC 或 吞吐率GC(parallel or throughput garbage collector)：适合占用記憶體較多，多CPU，追求高吞吐率的應用
- 并發GC：适合占用記憶體較多，多CPU的應用，對延遲有要求的應用
回到頂部
五、對象存活的判斷
判斷對象是否存活一般有兩種方式：
引用計數：每個對象有一個引用計數屬性，新增一個引用時計數加1，引用釋放時計數減1，計數為0時可以回收。此方法簡單，缺點是無法解決對象互相循環引用的問題。
可達性分析（Reachability Analysis）：從GC Roots開始向下搜尋，搜尋所走過的路徑稱為引用鍊。當一個對象到GC Roots沒有任何引用鍊相連時，則證明此對象是不可用的。不可達對象。
在Java語言中，GC Roots包括：
虛拟機棧中引用的對象。
方法區中類靜态屬性實體引用的對象。
方法區中常量引用的對象。
本地方法棧中JNI引用的對象。
由于循環引用的問題，一般采用跟蹤（可達性分析）方法
回到頂部
六、垃圾回收算法
6.1 标記 -清除算法
“标記-清除”（Mark-Sweep）算法，如它的名字一樣，算法分為“标記”和“清除”兩個階段：首先标記出所有需要回收的對象，在标記完成後統一回收掉所有被标記的對象。之是以說它是最基礎的收集算法，是因為後續的收集算法都是基于這種思路并對其缺點進行改進而得到的。
它的主要缺點有兩個：一個是效率問題，标記和清除過程的效率都不高；另外一個是空間問題，标記清除之後會産生大量不連續的記憶體碎片，空間碎片太多可能會導緻，當程式在以後的運作過程中需要配置設定較大對象時無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作。
6.2 複制算法
“複制”（Copying）的收集算法，它将可用記憶體按容量劃分為大小相等的兩塊，每次隻使用其中的一塊。當這一塊的記憶體用完了，就将還存活着的對象複制到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。
這樣使得每次都是對其中的一塊進行記憶體回收，記憶體配置設定時也就不用考慮記憶體碎片等複雜情況，隻要移動堆頂指針，按順序配置設定記憶體即可，實作簡單，運作高效。隻是這種算法的代價是将記憶體縮小為原來的一半，持續複制長生存期的對象則導緻效率降低。
6.3 标記-整理算法
複制收集算法在對象存活率較高時就要執行較多的複制操作，效率将會變低。更關鍵的是，如果不想浪費50%的空間，就需要有額外的空間進行配置設定擔保，以應對被使用的記憶體中所有對象都100%存活的極端情況，是以在老年代一般不能直接選用這種算法。
根據老年代的特點，有人提出了另外一種“标記-整理”（Mark-Compact）算法，标記過程仍然與“标記-清除”算法一樣，但後續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然後直接清理掉端邊界以外的記憶體
6.4 分代收集算法
GC分代的基本假設：絕大部分對象的生命周期都非常短暫，存活時間短。
“分代收集”（Generational Collection）算法，把Java堆分為新生代和老年代，這樣就可以根據各個年代的特點采用最适當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，隻有少量存活，那就選用複制算法，隻需要付出少量存活對象的複制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進行配置設定擔保，就必須使用“标記-清理”或“标記-整理”算法來進行回收。
回到頂部
七、垃圾收集器
如果說收集算法是記憶體回收的方法論，垃圾收集器就是記憶體回收的具體實作，不同廠商、不同版本的虛拟機實作差别很大，HotSpot中包含的收集器如下：
7.1 Serial收集器
串行收集器是最古老，最穩定以及效率高的收集器，可能會産生較長的停頓，隻使用一個線程去回收。新生代、老年代使用串行回收；新生代複制算法、老年代标記-壓縮；垃圾收集的過程中會Stop The World（服務暫停）
參數控制：-XX:+UseSerialGC 串行收集器
7.2 ParNew收集器
ParNew收集器其實就是Serial收集器的多線程版本。新生代并行，老年代串行；新生代複制算法、老年代标記-壓縮
參數控制：-XX:+UseParNewGC ParNew收集器
-XX:ParallelGCThreads 限制線程數量
7.3 Parallel收集器
Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量。可以通過參數來打開自适應調節政策，虛拟機會根據目前系統的運作情況收集性能監控資訊，動态調整這些參數以提供最合适的停頓時間或最大的吞吐量；也可以通過參數控制GC的時間不大于多少毫秒或者比例；新生代複制算法、老年代标記-壓縮
參數控制：-XX:+UseParallelGC 使用Parallel收集器+ 老年代串行
7.4 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數量）
7.5 G1收集器
G1是目前技術發展的最前沿成果之一，HotSpot開發團隊賦予它的使命是未來可以替換掉JDK1.5中釋出的CMS收集器。與CMS收集器相比G1收集器有以下特點：
1. 空間整合，G1收集器采用标記整理算法，不會産生記憶體空間碎片。配置設定大對象時不會因為無法找到連續空間而提前觸發下一次GC。
2. 可預測停頓，這是G1的另一大優勢，降低停頓時間是G1和CMS的共同關注點，但G1除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明确指定在一個長度為N毫秒的時間片段内，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已經是實時Java（RTSJ）的垃圾收集器的特征了。
上面提到的垃圾收集器，收集的範圍都是整個新生代或者老年代，而G1不再是這樣。使用G1收集器時，Java堆的記憶體布局與其他收集器有很大差别，它将整個Java堆劃分為多個大小相等的獨立區域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是實體隔閡了，它們都是一部分（可以不連續）Region的集合。
G1對Heap的劃分
JVM的垃圾回收算法以及GC收集器 JVM的GC垃圾收集器
G1的新生代收集跟ParNew類似，當新生代占用達到一定比例的時候，開始出發收集。和CMS類似，G1收集器收集老年代對象會有短暫停頓。
收集步驟
1、标記階段，首先初始标記(Initial-Mark),這個階段是停頓的(Stop the World Event)，并且會觸發一次普通Mintor GC。對應GC log:GC pause (young) (inital-mark)
2、Root Region Scanning，程式運作過程中會回收survivor區(存活到老年代)，這一過程必須在young GC之前完成。
3、Concurrent Marking，在整個堆中進行并發标記(和應用程式并發執行)，此過程可能被young GC中斷。在并發标記階段，若發現區域對象中的所有對象都是垃圾，那個這個區域會被立即回收(圖中打X)。同時，并發标記過程中，會計算每個區域的對象活性(區域中存活對象的比例)。
JVM的垃圾回收算法以及GC收集器 JVM的GC垃圾收集器
4、Remark, 再标記，會有短暫停頓(STW)。再标記階段是用來收集 并發标記階段 産生新的垃圾(并發階段和應用程式一同運作)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
5、Copy/Clean up，多線程清除失活對象，會有STW。G1将回收區域的存活對象拷貝到新區域，清除Remember Sets，并發清空回收區域并把它傳回到空閑區域連結清單中。
JVM的垃圾回收算法以及GC收集器 JVM的GC垃圾收集器
6、複制/清除過程後。回收區域的活性對象已經被集中回收到深藍色和深綠色區域。
JVM的垃圾回收算法以及GC收集器 JVM的GC垃圾收集器
回到頂部
八、常用的收集器組合
| 新生代GC政策 | 年老代GC政策 | 說明 |
組合1 Serial Serial Old Serial和Serial Old都是單線程進行GC，特點就是GC時暫停所有應用線程。 組合2 Serial CMS+Serial Old CMS（Concurrent Mark Sweep）是并發GC，實作GC線程和應用線程并發工作，不需要暫停所有應用線程。另外，當CMS進行GC失敗時，會自動使用Serial Old政策進行GC。 組合3 ParNew CMS 使用-XX:+UseParNewGC選項來開啟。ParNew是Serial的并行版本，可以指定GC線程數，預設GC線程數為CPU的數量。可以使用-XX:ParallelGCThreads選項指定GC的線程數。 如果指定了選項-XX:+UseConcMarkSweepGC選項，則新生代預設使用ParNew GC政策。 組合4 ParNew Serial Old 使用-XX:+UseParNewGC選項來開啟。新生代使用ParNew GC政策，年老代預設使用Serial Old GC政策。 組合5 Parallel Scavenge Serial Old Parallel Scavenge政策主要是關注一個可控的吞吐量：應用程式運作時間 / (應用程式運作時間 + GC時間)，可見這會使得CPU的使用率盡可能的高，适用于背景持久運作的應用程式，而不适用于互動較多的應用程式。 組合6 Parallel Scavenge Parallel Old Parallel Old是Serial Old的并行版本
組合7 G1GC G1GC -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC #開啟
-XX:MaxGCPauseMillis =50 #暫停時間目标
-XX:GCPauseIntervalMillis =200 #暫停間隔目标
-XX:+G1YoungGenSize=512m #年輕代大小
-XX:SurvivorRatio=6 #幸存區比例 原文路徑：https://www.cnblogs.com/qingyunzong/p/8973857.html