CMS收集器
一種以獲取最短回收停頓時間為目標的收集器「使ⅲ基于“標記-清除”算法實現(xiàn)的，整個過程分為4個步驟：
(1)初始標記（CMS initial mark）
(2)并發(fā)標記（CMS concurrent mark）
(3)重新標記（CMS remark）
(4)并發(fā)清除（CMS concurrent sweep）
其中初始標記疾党、重新標記仍然需要“Stop The World”间狂。初始標記僅僅只是標記一下GC Roots能直接關(guān)聯(lián)到的對象坦康，速度很快竣付，并發(fā)標記階段就是進行GC Roots Tracing的過程。而重新標記階段則是為了修正并發(fā)標記期間滞欠，因用戶程序繼續(xù)運作而導(dǎo)致標記產(chǎn)生變動的那一部分對象的標記記錄古胆，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比并發(fā)標記的時間短筛璧。
整個過程中耗時最長的并發(fā)標記和并發(fā)清除過程中逸绎，收集器線程都可以與用戶線程一起工作妖滔，所以總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)的執(zhí)行的桶良。
三個缺點：
（1）CMS收集器對CPU資源非常敏感。默認啟動的回收線程數(shù)是（CPU數(shù)量+3）/4;
（2）CMS收集器無法處理浮動垃圾沮翔，可能出現(xiàn)“Concurrent ModeFailure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生陨帆。
“浮動垃圾”指CMS并發(fā)清理階段用戶線程還在運行，伴隨程序運行自然有新的垃圾不斷產(chǎn)生采蚀，這部分垃圾出現(xiàn)在標記過程之后疲牵，只能留待下一次GC時再清理掉。
（3）基于“標記-清除”榆鼠，收集結(jié)束時會有大量的空間碎片產(chǎn)生纲爸。
碎片過多可能出現(xiàn)，老年代有很大空間剩余妆够，但無法找到足夠大的連續(xù)空間來分配當前對象识啦，不得不提前觸發(fā)一次Full GC。
-XX:+UseCMSCompactAtFullCollection（默認開啟）神妹，用于在CMS收集器頂不住要進行Full GC時開啟內(nèi)存碎片的合并整理過程颓哮。
-XX:CMSFullGCsBeforeCompaction，這個參數(shù)用于設(shè)置執(zhí)行多少次不壓縮的Full GC后鸵荠，跟著來一次帶壓縮的冕茅。
7、G1收集器
運行步驟：
1蛹找、初始標記
2姨伤、并發(fā)標記
3、最終標記
4庸疾、篩選回收
特點：并行與并發(fā)
分代收集
空間整合：基于“標記-整理”乍楚，G1運行期間不會產(chǎn)生內(nèi)存空間碎片，收集后能提供規(guī)整可用的可用內(nèi)存彼硫，有利于程序長時間運行炊豪。
可預(yù)測的停頓：能讓使用者指定在一個長度為M毫秒的時間片段內(nèi)，消耗在垃圾收集上的時間不得超過N毫秒拧篮。
G1收集器將整個java堆劃分為多個大小相等的獨立區(qū)域（Region）,跟蹤各個Region里面垃圾堆積的價值大写什场（回收所獲得空間大小以及回收所需的時間經(jīng)驗值），在后臺維護一個優(yōu)先列表串绩，每次根據(jù)允許的收集時間缺虐，優(yōu)先回收價值最大的Region
