JVM垃圾回收器、記憶體分配與回收策略
- 2020 年 11 月 26 日
- 筆記
- JAVA, JVM, JVM垃圾回收器、記憶體分配與回收策略
1. Serial收集器
serial收集器即串列收集器，是一個單執行緒收集器。
串列收集器在進行垃圾回收時只使用一個CPU或一條收集執行緒去完成垃圾回收工作，並且會暫停其他的工作執行緒（stop the world），直至回收完成。適用於運行在client模式下的JVM。
在單CPU年代，串列收集器是默認的垃圾回收器，minor GC和major GC的過程都是用一個執行緒去處理的。
啟用方式：-XX: +UseSerialGC
2. ParNew收集器
parNew收集器即並行收集器，採用的是多執行緒方式進行垃圾回收，可以理解為Serial收集器的多執行緒版本，吞吐量要比串列高很多，是伺服器級別的虛擬機默認使用的，用來處理新生代的垃圾回收器。
因為採用的是並行多執行緒方式，建議在多CPU環境下使用，否則和Serial沒有區別。
啟用方式：-XX: +UseParNewGC
3. Parallel Scavenge收集器
並行的多執行緒垃圾收集器，採用複製演算法進行垃圾回收，非常適合伺服器做計算任務時使用。
一般的垃圾回收器是在盡量短的時間內進行垃圾回收，這樣程式與用戶交互的時間間隔比較小，不會出現長時間的卡頓現象。但是Parallel Scavenge更側重於系統的吞吐量，高效的利用CPU，優先處理計算任務，適合交互少、運算多的場景。
通過參數-XX: MaxGcPauseMills設置GC最大停頓時間，通過參數-XX: GCTimeRatio設置吞吐量大小。
啟用方式：-XX: +UseParallelGC
老年代垃圾收集器
1. Serial Old收集器
serial收集器的老年代版本，同樣是單執行緒收集器、stop the world，使用標記整理演算法。一般啟用方式：UseSerialGC是Serial + Serial OldUseParNewGC是ParNew + Serial OldUseParallelGC是Parallel Scavenge + Serial Old
2. Parallel Old收集器
老年代版本的Parallel Scavenge，使用多執行緒 + 標記整理演算法。啟用方式：-XX: +UseParallelOldGC
3. CMS垃圾收集器
CMS收集器的主要目的是使垃圾回收造成的停頓時間最短，提高服務響應速度，使用標記清除演算法，具有並發收集（用戶執行緒與垃圾收集並發執行）、低停頓的特點。運行過程分為以下四個步驟：
1. 初始標記：stop the world，只是標記一下GC Roots能直接關聯到的對象，速度快
2. 並發標記：進行GC RootsTracing過程
3. 重新標記：stop the world，修正並發標記期間因用戶程式繼續運行而導致的標記產生變動的那部分對象的標記記錄。這個階段停頓時間相對初始標記時間長，比並發標記時間短
4. 並發清除注意：
- CMS收集器對CPU資源敏感，這是面向並發程式設計的共性
- 無法處理浮動垃圾（CMS垃圾收集階段，用戶執行緒仍在運行，因此會有新的垃圾生成，這部分垃圾只能在下一次GC時再清理，即浮動垃圾），可能出現”Concurrent Mode Failure”失敗導致另一次full GC
啟用方式：-XX:+UseConcMarkSweepGC
G1收集器
G1收集器是基於標記整理演算法實現的收集器，所以它不會產生記憶體空間碎片，並且可以精確的控制停頓時間。能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒。
G1的設計原則就是簡單可行的性能調優，只需聲明以下參數即可：
-XX:+UseG1GC -Xmx16g -XX:MaxGCPauseMills=300
其中，-XX:+UseG1GC表明開啟G1收集器，-Xmx16g設置堆記憶體為16g，-XX:MaxGCPauseMills=300設置GC停頓最大時間為300ms。如果我們需要調優，在記憶體一定的情況下，可以考慮修改該參數，當然還要根據實際業務場景來處理。
G1取消了堆內結構的新生代、老年代的物理空間劃分，將整個Java堆劃分為大小固定的獨立區域，後台維護一個優先列表來跟蹤這些區域的垃圾堆積程度，每次根據允許收集的時間，優先回收垃圾最多的區域。
G1中的Humongous區域用於存儲生命周期較短的巨型對象（一個對象所佔空間超過了分區容量的50%），如果一個Humongous區無法裝下一個巨型對象，G1會尋找連續的H分區來存儲，如果沒有連續的H區滿足這種情況，有時候會觸發full GC。
G1收集器的運作主要劃分為以下四個步驟：
- 初始標記：標記GC Roots能直接關聯到的對象，需要停頓執行緒，但耗時很短
- 並發標記：從GC Roots開始對堆中對象進行可達性分析，找出存活的對象，這階段耗時較長，但可與用戶程式並發執行
- 最終標記：修正在並發標記期間因用戶程式繼續運作而導致標記產生變動的那一部分標記記錄
- 篩選回收：對各個Region的回收價值和成本進行排序，根據用戶所期望的GC停頓時間來制定回收計劃
記憶體分配與回收策略
對象的記憶體分配主要是指在Java堆上的分配，通常會優先分配在新生代，然後經歷一系列GC後仍然存活的對象會進入到老年代。少數情況下，一些對象也會直接進入到老年代。
-Xms：設置初始化堆記憶體，-Xmx設置最大堆記憶體，設置為相等可防止記憶體抖動（剩餘記憶體大於70%、小於40%時，自動觸發記憶體擴大或縮小）
1. 對象會優先分配在新生代
新生代劃分為一個eden區和兩個survivor區（from survivor、to survivor）。初始階段，新創建的對象會分配給eden區。新生代發生的GC成為minor GC即Young GC，主要分為以下幾個過程：
- 隨著eden區存儲的對象不斷增多，當eden區剩餘空間無法存儲新生成的對象時會觸發GC
- 經過minor GC後仍然存活的對象會進入from survivor區
- 當再次觸發GC時，會掃描eden區和from survivor區，對這兩個區域進行垃圾回收，仍然存活的對象會被複制到to survivor區，同時這些存活的對象年齡加1
- 清空eden、from survivor區中的對象，並將from survivor和to survivor區互換
- 頻繁執行上述過程，當剩餘存活對象年齡達到15（默認）時，這些對象會進入老年代，通過參數-XX:MaxTenuringThreshold控制
-Xmn用來設置新生代大小，一般設置為整個堆記憶體的3/1或者1/4
-XX:NewRatio設置新生代與老年代的堆記憶體比例
-XX:SurvivorRatio設置eden區和survivor區之間的比例
2. 老年代存儲的對象
發生在老年代的GC是major GC，回收速度會比minor GC慢。
上文已經說明了對象進入老年代的一種情況即長期存活的對象會進入老年代，這裡再來看看其他情況：
1. 大對象直接進入老年代大對象需要的連續存儲空間（如數組）大於新生代剩餘空間時，會直接進入老年代。
通過參數-XX:PretenureSizeThreshold設置，大於該參數值的對象會直接進入老年代（避免新生代中大量對象的拷貝，效率低）
注意：PretenureSizeThreshold參數只對部分垃圾回收器有效，比如Serial和ParNew
2. 如果survivor區相同年齡所有對象大小的總和大於survivor空間的一半，年齡大於或等於該年齡的對象可以直接進入老年代，無需等到MaxTenuringThreshold設置的年齡
注意：永久代不屬於堆空間，通過參數-XX:PermSize，-XX:MaxPermSize控制大小
3. Full GC
full GC是針對整個Java堆空間進行垃圾回收，包括新生代和老年代，會造成stop world。要盡量避免full GC，它會影響程式的穩定性。
導致Full GC的幾點原因：
1. 老年代空間不足從年輕代進入老年代的對象所佔空間大於老年代剩餘空間大小。eden區調大一些，盡量讓對象在新生代minor GC回收，而不是集中在老年代進行major GC，盡量不要創建特別大的對象
2. 垃圾回收演算法用的不對比如在老年代使用複製收集演算法
3. 永久代空間不足
4. 被HandlePromotionFailure參數強制Full GC
在發生minor GC時，虛擬機會檢測之前每次晉陞到老年代的平均大小是否大於老年代的剩餘空間大小，如果大於，則改為進行full GC。如果小於，則根據HandlePromotionFailure的設置是否允許擔保分配記憶體失敗：如果允許失敗，則只進行minor GC；反之，則進行full GC。
但是如果發生HandlePromotionFailure失敗，則會進行full GC。
關注微信公眾號：大數據學習與分享，獲取更對技術乾貨
