JVM-垃圾收集器

   

 

Parallel Scavenge：吞吐量優先收集器

吞吐量：CPU用於運行用戶代碼的時間與CPU總消耗時間的比值，（吞吐量Throughput = 運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間） or 吞吐量=（JVM運行時間-GC時間）/JVM運行時間）

停頓時間：

吞吐量：適合後臺運算而不須要太多交互的任務；

Parallel Scavenge+Parallel Old：在注重吞吐量以及CPU資源敏感的場景，可優先考慮

CMS：低停頓收集器

CMS 默認啓動的回收線程數是（CPU數+3）/4，即CPU在4個以上時，併發回收時GC線程>=25%的CPU資源，且隨着CPU數的增長而降低。

CPU數1->GC數：（1+3）/4=1

CPU數2->GC數：（2+3）/4=1.25【？】

CPU數4->GC數：（4+3）/4=1.75【？】

CPU數8->GC數：（8+3）/4=2.75【？】

CPU數16->GC數：（16+3）/4=4.75【？】

CPU數32->GC數：（32+3）/4=8.75【？】

CPU數64->GC數：（64+3）/4=16.75【？】

CMS中的「浮動垃圾」【Floating Garbage】：併發清理階段用戶線程還在運行，這段時間就可能產生新的垃圾，新的垃圾在這次GC沒法清除，只能等到下次清理。這些垃圾叫浮動垃圾。

 

	Serial	ParNew	Parallel Scavenge	Serial Old	Parallel Old	CMS	G1收集器
簡介			吞吐量優先收集器 自適應調節方式	是Serial的老年代版本	是Parallel Scavenge的老年代版本	低停頓收集器 Mark Sweep即標記-清除算法
關注點			達到一個可控的吞吐量			最短回收停頓時間
優勢	簡單而高效（與其餘收集器的單線程比）					併發收集、低停頓	低停頓，停頓時間可控
缺點						1.對CPU資源很是敏感，默認啓動的回收線程數是（CPU數+3）/4，即CPU在4個以上時，併發回收時GC線程>=25%的CPU資源，且隨着CPU數的增長而降低。 2.CMS沒法處理浮動垃圾（Floating Garbage），可能出現「Concurrent Mode Failure」失敗而致使另外一次Full GC產生。   -XX:CMSInitiatingOccupancyFraction的值來設定觸發百分比 JDK1.5：默認68%，若應用中老年代增加不是太快，能夠適當調高； JDK1.6：默認92% 若CMS運行期間預留的內存沒法知足程序須要，就會出現「Concurrent Mode Failure」失敗，此時啓動後備預案，臨時使用Serial Old，此時停頓超長，所以不能設置過高，容易致使大量Concurrent Mode Failure失敗，性能反而下降； 3.標記-清除，會有大量空間碎片產生。空間碎片過多時，會給大對象分配帶來麻煩，每每會出現老年代還有很大空間剩餘，但沒法找到足夠大的連續空間來分配當前對象，不得不提早觸發1次FGC。 -XX:+UseCMSCompactAtFullCollection 默認爲0，設置執行多少次不壓縮的FGC後，來一次帶壓縮的。
產生版本					JDK1.6	JDK1.5	JDK1.7
收集範圍	新生代	新生代	新生代				整個Java堆劃分紅大小相等的獨立區域（Region） 新生代：部分Region的集合（不須要連續） 老年代：部分Region的集合（不須要連續）
收集方案	新生代：複製算法	新生代：複製算法 除了使用多線程，其餘大多和Serial徹底同樣	新生代：複製算法				優先列表：優先回收價值最大的Region 優先列表內容：維護各個Region回收所得到的空間大小及回收所需時間的經驗值
適合領域	Client模式下的虛擬機（如：桌面應用場景）	Server下首選（重要由於只有ParNew能夠與CMS配合工做）		主要意義：Client模式下的虛擬機 server模式下： 1.JDK1.5及之前版本中與Parallel Scavenge搭配； 2.做爲 CMS的後備預案，在CMS發生Concurrent Mode Failure時使用；			服務端應用
使命							替換掉JDK1.5中的CMS
是否多線程	單線程 只用1個CPU、1條GC線程去完成GC工做， 且需暫停其餘全部工做線程，直到GC結束	多線程 多條GC線程去完成GC工做， 且需暫停其餘全部工做線程，直到GC結束					多線程
並行（Parallel） 多條GC線程並行工做，但用戶線程需等待	並行	並行	並行				與Java線程並行
併發（Concurrent） 用戶線程與GC線程同時執行，在不一樣的CPU上							使用多CPU來縮短Stop The World停頓時間
分代收集							是【可獨立管理整個堆】
空間整合							總體基於「標記-整理」算法，局部（兩個Region間）基於「複製」算法，
是否會產生空間碎片							不會產生空間碎片，有利於程序長時間運行
可預測的停頓						下降停頓	下降停頓，創建可預測的停頓時間模型（在M毫秒內，消耗在垃圾收集上的時間不得超過N毫秒） 緣由：有計劃的避免在整個Java堆中進行全區域的GC
維護Remembered Set							對引用類型數據寫時，會中斷一下，檢查其引用的對象是否處於不一樣的Region中，如果，便經過CardTable記錄到R Set中
不對全堆掃描處理							在GC根節點的枚舉範圍中加入Remembered Set便可
1初始標記						【停頓】僅僅標記GC Roots能直接關聯到的對象	【停頓】【耗時短】 標記GC Roots能直接關聯到的對象 修改TAMS，讓以後能在正確可用的Region中建立新對象
2併發標記						【併發】進行GC Roots Tracing	【耗時長】 【與用戶程序並行執行】 從GC Root開始，對堆中對象進行可達性分析，找出存活對象
3最終標記						【停頓】 從新標記 修正併發標記期間用戶程序致使標記變更的那部分對象的標記記錄 比階段1長，但遠比階段2短	【停頓】【GC多線程並行執行】 目的：修正在併發標記期間用戶程序運行致使標記產生變更的那一部分標記記錄， 這段時間的對象變化記錄在現場Remembered Set Logs裏， 把Remembered Set Logs的數據合併到Remembered Set，
4併發清除
參數		-XX:+UseConcMarkSweepGC 選項後默認使用ParNew -XX:+UseParNewGC 強制使用ParNew -XX:ParallelGCThreads 設定垃圾收集的線程數（必須：建議值等於容器核數）	-XX:MaxGCPauseMillis 控制最大的GC停頓時間 -XX:GCTimeRatio 直接設置吞吐量 （GCTimeRatio默認99，即容許最大垃圾收集時間=1/(1+99)=1%） GC自適應調節策略GC Ergonomics：（須要設定最大堆-Xmx 、最大停頓或吞吐量） -XX:+UseAdaptiveSizePolicy 開關參數，打開後不須要手工指定-Xmn、-XX:SurvivorRatio、-XX:PretenureSizeThreshold等細節參數，			-XX:CMSInitiatingOccupancyFraction的值來設定觸發百分比 JDK1.5：默認68%，若應用中老年代增加不是太快，能夠適當調高； JDK1.6：默認92%； -XX:+UseCMSCompactAtFullCollection 默認爲0，設置執行多少次不壓縮的FGC後，來一次帶壓縮的。	-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200 -XX:ParallelGCThreads=n 設置 STW 工做線程數的值。設爲服務虛擬內核數，n 的值與邏輯處理器的數量相同，最多爲 8，若是邏輯處理器不止八個，則將 n 的值設置爲邏輯處理器數的 5/8 左右。這適用於大多數狀況，除非是較大的 SPARC 系統，其中 n 的值能夠是邏輯處理器數的 5/16 左右。 -XX:ConcGCThreads=n 設置並行標記的線程數。將 n 設置爲並行垃圾回收線程數 (ParallelGCThreads) 的 1/4 左右。