程序計數器，棧和本地方法棧隨線程而滅，但是堆和方法區所需要的內存不確定，只有到程序運行期間才能指定要創建哪些對象，這部分的內存分配和回收是動態的
1.垃圾收集器在對堆進行回收時，需要確定哪些對象還“存活”，
- 引用計數算法(java中沒有用來管理內存)，雖然簡單，但是難以解決對象之間相互循環引用的問題
- 根搜索算法：
由於引用計數算法的缺陷，所以JVM一般會採用一種新的算法，叫做根搜索算法。它的處理方式就是，設立若干種根對象，當任何一個根對象到某一個對象均不可達時，則認爲這個對象是可以被回收的。
![]()
就拿上圖來說，ObjectD和ObjectE是互相關聯的，但是由於GC roots到這兩個對象不可達，所以最終D和E還是會被當做GC的對象，上圖若是採用引用計數法，則A-E五個對象都不會被回收，說到GC roots（GC根），在JAVA語言中，可以當做GC roots的對象有以下幾種：
1、虛擬機棧中的引用的對象。
2、方法區中的類靜態屬性引用的對象。
3、方法區中的常量引用的對象。
4、本地方法棧中JNI的引用的對象。
第一和第四種都是指的方法的本地變量表，第二種表達的意思比較清晰，第三種主要指的是聲明爲final的常量值。
根搜索算法解決的是垃圾蒐集的基本問題，也就是上面提到的第一個問題，也是最關鍵的問題，就是哪些對象可以被回收，不過垃圾收集顯然還需要解決後兩個問題，什麼時候回收以及如何回收，在根搜索算法的基礎上，現代虛擬機的實現當中，垃圾蒐集的算法主要有三種，分別是標記-清除算法、複製算法、標記-整理算法，這三種算法都擴充了根搜索算法，不過它們理解起來還是非常好理解的。
根搜索算法（並沒有解決如何回收和何時回收兩個問題），它可以解決我們應該回收哪些對象的問題，但是它顯然還不能承擔垃圾蒐集的重任，因爲我們在程序（程序也就是指我們運行在JVM上的JAVA程序）運行期間如果想進行垃圾回收，就必須讓GC線程與程序當中的線程互相配合，才能在不影響程序運行的前提下，順利的將垃圾進行回收。因此出現了下面幾種基於根搜索算法的算法。
2.垃圾收集算法：引用計數法，標記-清除算法、複製算法（新生代）、標記-整理算法（老生代），分代算法(複製算法+標記-整理算法)，分區算法
（1） 引用計數法
引用計數法是最經典的一種垃圾回收算法。其實現很簡單，對於一個A對象，只要有任何一個對象引用了A，則A的引用計算器就加1，當引用失效時，引用計數器減1.只要A的引用計數器值爲0，則對象A就不可能再被使用。
雖然其思想實現都很簡單（爲每一個對象配備一個整型的計數器），但是該算法卻存在兩個嚴重的問題：
1） 無法處理循環引用的問題，因此在Java的垃圾回收器中，沒有使用該算法。
2） 引用計數器要求在每次因引用產生和消除的時候，需要伴隨一個加法操作和減法操作，對系統性能會有一定的影響。
一個簡單的循環引用問題描述：
對象A和對象B，對象A中含有對象B的引用，對象B中含有對象A的引用。此時對象A和B的引用計數器都不爲0，但是系統中卻不存在任何第三個對象引用A和B。也就是說A和B是應該被回收的垃圾對象，但由於垃圾對象間的互相引用使得垃圾回收器無法識別，從而引起內存泄漏（由於某種原因不能回收垃圾對象佔用的內存空間）。
如下圖：不可達對象出現循環引用，它的引用計數器不爲0，
注意：由於引用計數器算法存在循環引用以及性能的問題，java虛擬機並未使用此算法作爲垃圾回收算法。
【可達對象】：通過根對象的進行引用搜索，最終可以到達的對象。
【不可達對象】：通過根對象進行引用搜索，最終沒有被引用到的對象。
2）標記清除法
標記清除法是現代垃圾回收算法的思想基礎。
標記清除法將垃圾回收分爲兩個階段：標記階段和清除階段。
在標記階段，首先通過根節點，標記所有從根節點開始的可達對象，因此未被標記的對象就是未被引用的垃圾對象。然後在清除階段，清除所有未被標記的對象。這種方法可以解決循環引用的問題，只有兩個對象不可達，即使它們互相引用也無濟於事。也是會被判定位不可達對象。
標記清除算法可能產生的最大的問題就是空間碎片。
如下圖所示，簡單描述了使用標記清除法對一塊連續的內存空間進行回收。
從根節點開始（在這裏僅顯示了兩個根節點），所有的有引用關係的對象均被標記爲存活對象（箭頭表示引用）。從根節點起，不可達對象均爲垃圾對象。在標記操作完成後，系統回收所有不可達對象。
從上圖可以看出，回收後的內存空間不再連續。在對象的對空間分配過程中，尤其是大對象的內存分配，不連續內存空間的工作效率要低於連續空間的，這也是該算法的缺點。
注意：標記清除算法先通過根節點標記所有可達對象，然後清除所有不可達對象，完成垃圾回收。後面會講到標記壓縮算法，注意兩者的區別。。。。。。
（3） 複製算法
算法思想：將原有的內存空間分爲兩塊相同的存儲空間，每次只使用一塊，在垃圾回收時，將正在使用的內存塊中存活對象複製到未使用的那一塊內存空間中，之後清除正在使用的內存塊中的所有對象，完成垃圾回收。
如果系統中的垃圾對象很多，複製算法需要複製的存活對象就會相對較少（適用場景）。因此，在真正需要垃圾回收的時刻，複製算法的效率是很高的。而且，由於存活對象在垃圾回收過程中是一起被賦值到另一塊內存空間中的，因此，可確保回收的內存空間是沒有碎片的。（優點）
但是複製算法的代價是將系統內存空間折半，只使用一半空間，而且如果內存空間中垃圾對象少的話，複製對象也是很耗時的，因此，單純的複製算法也是不可取的。（缺點）
圖解算法回收流程：
A、B兩塊相同的內存空間（原有內存空間折半得到的兩塊相同大小內存空間AB），A在進行垃圾回收，將存活的對象複製到B中，B中的空間在複製後保持連續。完成複製後，清空A。並將空間B設置爲當前使用內存空間。
在java中的新生代串行垃圾回收器中，使用了複製算法的思想，新生代分爲eden空間、from空間和to空間3個部分，其中from和to空間可以看做用於複製的兩塊大小相同、可互換角色的內存空間塊（同一時間只能有一個被當做當前內存空間使用，另一個在垃圾回收時才發揮作用），from和to空間也稱爲survivor空間，用於存放未被回收的對象。
【新生代對象】：存放年輕對象的堆空間，年輕對象指剛剛創建，或者經歷垃圾回收次數不多的對象。
【老年代對象】：存放老年對象的堆空間。即爲經歷多次垃圾回收依然存活的對象。
在垃圾回收時，eden空間中存活的對象會被複制到未使用的survivor空間中（圖中的to），正在使用的survivor空間（圖中的from）中的年輕對象也會被複制到to空間中（大對象或者老年對象會直接進入老年代，如果to空間已滿，則對象也會進入老年代）。此時eden和from空間中剩餘對象就是垃圾對象，直接清空，to空間則存放此次回收後存活下來的對象。
優點：這種複製算法保證了內存空間的連續性，又避免了大量的空間浪費。
注意：複製算法比較適用於新生代。因爲在新生代中，垃圾對象通常會多於存活對象，算法的效果會比較好。
（4） 標記壓縮算法
複製算法的高效性是建立在存活對象少、垃圾對象多的情況下，這種情況在新生代比較常見，
但是在老年代中，大部分對象都是存活的對象，如果還是有複製算法的話，成本會比較高。因此，基於老年代這種特性，應該使用其他的回收算法。
標記壓縮算法是老年代的回收算法，它在標記清除算法的基礎上做了優化。（回憶一下，標記清除算法的缺點，垃圾回收後內存空間不再連續，影響了內存空間的使用效率。。。）
和標記清除算法一樣，標記壓縮算法也首先從根節點開始，對所有可達的對象做一次標記，
但之後，它並不是簡單的清理未標記的對象，而是將所有的存活對象壓縮到內存空間的一端，之後，清理邊界外所有的空間。
這樣做避免的碎片的產生，又不需要兩塊相同的內存空間，因此性價比高。
圖解其算法工作過程：
通過根節點標記出所有的可達對象後，沿着虛線進行對象的移動，將所有的可達對象移到一端，並保持他們之間的引用關係，最後，清理邊界外的空間。
標記壓縮算法的最終效果等同於標記清除算法執行完成後，再進行一次內存碎片的整理，因此也稱之爲標記清除壓縮算法。
（5） 分代算法
前面介紹的垃圾回收算法中，並沒有一種算法可以完全替代其他算法，各自具有自己的特點和優勢，因此需要根據垃圾對象的特性選擇合適的垃圾回收算法。
分代算法思想：將內存空間根據對象的特點不同進行劃分，選擇合適的垃圾回收算法，以提高垃圾回收的效率。
通常，java虛擬機會將所有的新建對象都放入稱爲新生代的內存空間。
新生代的特點是：對象朝生夕滅，大約90%的對象會很快回收，因此，新生代比較適合使用複製算法。
當一個對象經過幾次垃圾回收後依然存活，對象就會放入老年代的內存空間，在老年代中，幾乎所有的對象都是經過幾次垃圾回收後依然得以存活的，因此，認爲這些對象在一段時間內，甚至在程序的整個生命週期將是常駐內存的。
老年代的存活率是很高的，如果依然使用複製算法回收老年代，將需要複製大量的對象。這種做法是不可取的，根據分代的思想，對老年代的回收使用標記清除或者標記壓縮算法可以提高垃圾回收效率。
注意：分代的思想被現有的虛擬機廣泛使用，幾乎所有的垃圾回收器都區分新生代和老年代。
對於新生代和老年代來說，通常新生代回收的頻率很高，但是每次回收的時間都很短，而老年代回收的頻率比較低，但是被消耗很多的時間。爲了支持高頻率的新生代回收，虛擬機可能使用一種叫做卡表的數據結構，卡表爲一個比特位集合，每一個比特位可以用來表示老年代的某一區域中的所有對象是否持有新生代對象的引用，
這樣以來，新生代GC時，可以不用花大量時間掃描所有老年代對象，來確定每一個對象的引用關係，而可以先掃描卡表，只有當卡表的標記爲1時，才需要掃描給定區域的老年代對象，而卡表爲0的所在區域的老年代對象，一定不含有新生代對象的引用。
如下圖表示：
卡表中每一位表示老年代4KB的空間，卡表記錄爲0的老年代區域沒有任何對象指向新生代，只有卡表爲1的區域纔有對象包含新生代對象的引用，因此在新生代GC時，只需要掃面卡表爲1所在的老年代空間，使用這種方式，可以大大加快新生代的回收速度。
（6） 分區算法
算法思想：分區算法將整個堆空間劃分爲連續的不同小區間，
如圖所示：
每一個小區間都獨立使用，獨立回收。
算法優點是：可以控制一次回收多少個小區間
通常，相同的條件下，堆空間越大，一次GC所需的時間就越長，從而產生的停頓時間就越長。爲了更好的控制GC產生的停頓時間，將一塊大的內存區域分割成多個小塊，根據目標的停頓時間，每次合理的回收若干個小區間，而不是整個堆空間，從而減少一個GC的停頓時間。
垃圾收集器：
如果說收集算法是內存回收具體的方法論，那麼垃圾收集器就是內存回收的具體實現
垃圾收集器是垃圾回收算法（標記-清除算法、複製算法、標記-整理算法、火車算法）的具體實現，不同商家、不同版本的JVM所提供的垃圾收集器可能會有很在差別，本文主要介紹HotSpot虛擬機中的垃圾收集器。
1-1、垃圾收集器組合
JDK7/8後，HotSpot虛擬機所有收集器及組合（連線），如下圖：
（A）、圖中展示了7種不同分代的收集器：
Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1；
（B）、而它們所處區域，則表明其是屬於新生代收集器還是老年代收集器：
新生代收集器：Serial、ParNew、Parallel Scavenge；
老年代收集器：Serial Old、Parallel Old、CMS；
整堆收集器：G1；
（C）、兩個收集器間有連線，表明它們可以搭配使用：
Serial/Serial Old、Serial/CMS、ParNew/Serial Old、ParNew/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1；
（D）、其中Serial Old作爲CMS出現"Concurrent Mode Failure"失敗的後備預案（後面介紹）；
1-2、併發垃圾收集和並行垃圾收集的區別
（A）、並行（Parallel）
指多條垃圾收集線程並行工作，但此時用戶線程仍然處於等待狀態；
如ParNew、Parallel Scavenge、Parallel Old；
（B）、併發（Concurrent）
指用戶線程與垃圾收集線程同時執行（但不一定是並行的，可能會交替執行）；
用戶程序在繼續運行，而垃圾收集程序線程運行於另一個CPU上；
如CMS、G1（也有並行）；
1-3、Minor GC和Full GC的區別
（A）、Minor GC
又稱新生代GC，指發生在新生代的垃圾收集動作；
因爲Java對象大多是朝生夕滅，所以Minor GC非常頻繁，一般回收速度也比較快；
（B）、Full GC
又稱Major GC或老年代GC，指發生在老年代的GC；
出現Full GC經常會伴隨至少一次的Minor GC（不是絕對，Parallel Sacvenge收集器就可以選擇設置Major GC策略）；
Major GC速度一般比Minor GC慢10倍以上；
下面將介紹這些收集器的特性、基本原理和使用場景，並重點分析CMS和G1這兩款相對複雜的收集器；但需要明確一個觀點：
沒有最好的收集器，更沒有萬能的收集；
選擇的只能是適合具體應用場景的收集器。
2、Serial收集器
Serial（串行）垃圾收集器是最基本、發展歷史最悠久的收集器；
JDK1.3.1前是HotSpot新生代收集的唯一選擇；
1、特點
針對新生代；
採用複製算法；
單線程收集；
進行垃圾收集時，必須暫停所有工作線程，直到完成；
即會"Stop The World"；
Serial/Serial Old組合收集器運行示意圖如下：
2、應用場景
依然是HotSpot在Client模式下默認的新生代收集器；
也有優於其他收集器的地方：
簡單高效（與其他收集器的單線程相比）；
對於限定單個CPU的環境來說，Serial收集器沒有線程交互（切換）開銷，可以獲得最高的單線程收集效率；
在用戶的桌面應用場景中，可用內存一般不大（幾十M至一兩百M），可以在較短時間內完成垃圾收集（幾十MS至一百多MS）,只要不頻繁發生，這是可以接受的
3、設置參數
"-XX:+UseSerialGC"：添加該參數來顯式的使用串行垃圾收集器；
4、Stop TheWorld說明
JVM在後臺自動發起和自動完成的，在用戶不可見的情況下，把用戶正常的工作線程全部停掉，即GC停頓；
會帶給用戶不良的體驗；
從JDK1.3到現在，從Serial收集器-》Parallel收集器-》CMS-》G1，用戶線程停頓時間不斷縮短，但仍然無法完全消除；
更多"Stop The World"信息請參考：《Java虛擬機垃圾回收(一) 基礎》"2-2、可達性分析算法"
更多Serial收集器請參考：
《Memory Management in the Java HotSpot™ Virtual Machine》 4.3節 Serial Collector（內存管理白皮書）：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》 第5節 Available Collectors（官方的垃圾收集調優指南）：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref27
3、ParNew收集器
ParNew垃圾收集器是Serial收集器的多線程版本。
1、特點
除了多線程外，其餘的行爲、特點和Serial收集器一樣；
如Serial收集器可用控制參數、收集算法、Stop The World、內存分配規則、回收策略等；
兩個收集器共用了不少代碼；
ParNew/Serial Old組合收集器運行示意圖如下：
2、應用場景
在Server模式下，ParNew收集器是一個非常重要的收集器，因爲除Serial外，目前只有它能與CMS收集器配合工作；
但在單個CPU環境中，不會比Serail收集器有更好的效果，因爲存在線程交互開銷。
3、設置參數
"-XX:+UseConcMarkSweepGC"：指定使用CMS後，會默認使用ParNew作爲新生代收集器；
"-XX:+UseParNewGC"：強制指定使用ParNew；
"-XX:ParallelGCThreads"：指定垃圾收集的線程數量，ParNew默認開啓的收集線程與CPU的數量相同；
4、爲什麼只有ParNew能與CMS收集器配合
CMS是HotSpot在JDK1.5推出的第一款真正意義上的併發（Concurrent）收集器，第一次實現了讓垃圾收集線程與用戶線程（基本上）同時工作；
CMS作爲老年代收集器，但卻無法與JDK1.4已經存在的新生代收集器Parallel Scavenge配合工作；
因爲Parallel Scavenge（以及G1）都沒有使用傳統的GC收集器代碼框架，而另外獨立實現；而其餘幾種收集器則共用了部分的框架代碼；
關於CMS收集器後面會詳細介紹。
4、Parallel Scavenge收集器
Parallel Scavenge垃圾收集器因爲與吞吐量關係密切，也稱爲吞吐量收集器（Throughput Collector）。
1、特點
（A）、有一些特點與ParNew收集器相似
新生代收集器；
採用複製算法；
多線程收集；
（B）、主要特點是：它的關注點與其他收集器不同
CMS等收集器的關注點是儘可能地縮短垃圾收集時用戶線程的停頓時間；
而Parallel Scavenge收集器的目標則是達一個可控制的吞吐量（Throughput）；
關於吞吐量與收集器關注點說明詳見本節後面；
2、應用場景
高吞吐量爲目標，即減少垃圾收集時間，讓用戶代碼獲得更長的運行時間；
當應用程序運行在具有多個CPU上，對暫停時間沒有特別高的要求時，即程序主要在後臺進行計算，而不需要與用戶進行太多交互；
例如，那些執行批量處理、訂單處理、工資支付、科學計算的應用程序；
3、設置參數
Parallel Scavenge收集器提供兩個參數用於精確控制吞吐量：
（A）、"-XX:MaxGCPauseMillis"
控制最大垃圾收集停頓時間，大於0的毫秒數；
MaxGCPauseMillis設置得稍小，停頓時間可能會縮短，但也可能會使得吞吐量下降；
因爲可能導致垃圾收集發生得更頻繁；
（B）、"-XX:GCTimeRatio"
設置垃圾收集時間佔總時間的比率，0<n<100的整數；
GCTimeRatio相當於設置吞吐量大小；
垃圾收集執行時間佔應用程序執行時間的比例的計算方法是：
1 / (1 + n)
例如，選項-XX:GCTimeRatio=19，設置了垃圾收集時間佔總時間的5%--1/(1+19)；
默認值是1%--1/(1+99)，即n=99；
垃圾收集所花費的時間是年輕一代和老年代收集的總時間；
如果沒有滿足吞吐量目標，則增加代的內存大小以儘量增加用戶程序運行的時間；
此外，還有一個值得關注的參數：
（C）、"-XX:+UseAdptiveSizePolicy"
開啓這個參數後，就不用手工指定一些細節參數，如：
新生代的大小（-Xmn）、Eden與Survivor區的比例（-XX:SurvivorRation）、晉升老年代的對象年齡（-XX:PretenureSizeThreshold）等；
JVM會根據當前系統運行情況收集性能監控信息，動態調整這些參數，以提供最合適的停頓時間或最大的吞吐量，這種調節方式稱爲GC自適應的調節策略（GC Ergonomiscs）；
這是一種值得推薦的方式：
(1)、只需設置好內存數據大小（如"-Xmx"設置最大堆）；
(2)、然後使用"-XX:MaxGCPauseMillis"或"-XX:GCTimeRatio"給JVM設置一個優化目標；
(3)、那些具體細節參數的調節就由JVM自適應完成；
這也是Parallel Scavenge收集器與ParNew收集器一個重要區別；
更多目標調優和GC自適應的調節策略說明請參考：
《Memory Management in the Java HotSpot™ Virtual Machine》 5節 Ergonomics -- Automatic Selections and Behavior Tuning：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》 第2節 Ergonomics：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/ergonomics.html#ergonomics
4、吞吐量與收集器關注點說明
（A）、吞吐量（Throughput）
CPU用於運行用戶代碼的時間與CPU總消耗時間的比值；
即吞吐量=運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間）；
高吞吐量即減少垃圾收集時間，讓用戶代碼獲得更長的運行時間；
（B）、垃圾收集器期望的目標（關注點）
（1）、停頓時間
停頓時間越短就適合需要與用戶交互的程序；
良好的響應速度能提升用戶體驗；
（2）、吞吐量
高吞吐量則可以高效率地利用CPU時間，儘快完成運算的任務；
主要適合在後臺計算而不需要太多交互的任務；
（3）、覆蓋區（Footprint）
在達到前面兩個目標的情況下，儘量減少堆的內存空間；
可以獲得更好的空間局部性；
更多Parallel Scavenge收集器的信息請參考：
官方的垃圾收集調優指南 第6節：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html#parallel_collector
上面介紹的都是新生代收集器，接下來開始介紹老年代收集器；
5、Serial Old收集器
Serial Old是 Serial收集器的老年代版本；
1、特點
針對老年代；
採用"標記-整理"算法（還有壓縮，Mark-Sweep-Compact）；
單線程收集；
Serial/Serial Old收集器運行示意圖如下：
2、應用場景
主要用於Client模式；
而在Server模式有兩大用途：
（A）、在JDK1.5及之前，與Parallel Scavenge收集器搭配使用（JDK1.6有Parallel Old收集器可搭配）；
（B）、作爲CMS收集器的後備預案，在併發收集發生Concurrent Mode Failure時使用（後面詳解）；
更多Serial Old收集器信息請參考：
內存管理白皮書 4.3.2節：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
6、Parallel Old收集器
Parallel Old垃圾收集器是Parallel Scavenge收集器的老年代版本；
JDK1.6中才開始提供；
1、特點
針對老年代；
採用"標記-整理"算法；
多線程收集；
Parallel Scavenge/Parallel Old收集器運行示意圖如下：
2、應用場景
JDK1.6及之後用來代替老年代的Serial Old收集器；
特別是在Server模式，多CPU的情況下；
這樣在注重吞吐量以及CPU資源敏感的場景，就有了Parallel Scavenge加Parallel Old收集器的"給力"應用組合；
3、設置參數
"-XX:+UseParallelOldGC"：指定使用Parallel Old收集器；
更多Parallel Old收集器收集過程介紹請參考：
《內存管理白皮書》 4.5.2節： http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
7、CMS收集器
併發標記清理（Concurrent Mark Sweep，CMS）收集器也稱爲併發低停頓收集器（Concurrent Low Pause Collector）或低延遲（low-latency）垃圾收集器；
在前面ParNew收集器曾簡單介紹過其特點；
1、特點
針對老年代；
基於"標記-清除"算法(不進行壓縮操作，產生內存碎片)；
以獲取最短回收停頓時間爲目標；
併發收集、低停頓；
需要更多的內存（看後面的缺點）；
是HotSpot在JDK1.5推出的第一款真正意義上的併發（Concurrent）收集器；
第一次實現了讓垃圾收集線程與用戶線程（基本上）同時工作；
2、應用場景
與用戶交互較多的場景；
希望系統停頓時間最短，注重服務的響應速度；
以給用戶帶來較好的體驗；
如常見WEB、B/S系統的服務器上的應用；
3、設置參數
"-XX:+UseConcMarkSweepGC"：指定使用CMS收集器；
4、CMS收集器運作過程
比前面幾種收集器更復雜，可以分爲4個步驟:
（A）、初始標記（CMS initial mark）
僅標記一下GC Roots能直接關聯到的對象；
速度很快；
但需要"Stop The World"；
（B）、併發標記（CMS concurrent mark）
進行GC Roots Tracing的過程；
剛纔產生的集合中標記出存活對象；
應用程序也在運行；
並不能保證可以標記出所有的存活對象；
（C）、重新標記（CMS remark）
爲了修正併發標記期間因用戶程序繼續運作而導致標記變動的那一部分對象的標記記錄；
需要"Stop The World"，且停頓時間比初始標記稍長，但遠比並發標記短；
採用多線程並行執行來提升效率；
（D）、併發清除（CMS concurrent sweep）
回收所有的垃圾對象；
整個過程中耗時最長的併發標記和併發清除都可以與用戶線程一起工作；
所以總體上說，CMS收集器的內存回收過程與用戶線程一起併發執行；
CMS收集器運行示意圖如下：
5、CMS收集器3個明顯的缺點
（A）、對CPU資源非常敏感
併發收集雖然不會暫停用戶線程，但因爲佔用一部分CPU資源，還是會導致應用程序變慢，總吞吐量降低。
CMS的默認收集線程數量是=(CPU數量+3)/4；
當CPU數量多於4個，收集線程佔用的CPU資源多於25%，對用戶程序影響可能較大；不足4個時，影響更大，可能無法接受。
增量式併發收集器：
針對這種情況，曾出現了"增量式併發收集器"（Incremental Concurrent Mark Sweep/i-CMS）；
類似使用搶佔式來模擬多任務機制的思想，讓收集線程和用戶線程交替運行，減少收集線程運行時間；
但效果並不理想，JDK1.6後就官方不再提倡用戶使用。
更多請參考：
官方的《垃圾收集調優指南》8.8節 Incremental Mode：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#CJAGIIEJ
《內存管理白皮書》 4.6.3節可以看到一些描述；
（B）、無法處理浮動垃圾,可能出現"Concurrent Mode Failure"失敗
（1）、浮動垃圾（Floating Garbage）
在併發清除時，用戶線程新產生的垃圾，稱爲浮動垃圾；
這使得併發清除時需要預留一定的內存空間，不能像其他收集器在老年代幾乎填滿再進行收集；
也要可以認爲CMS所需要的空間比其他垃圾收集器大；
"-XX:CMSInitiatingOccupancyFraction"：設置CMS預留內存空間；
JDK1.5默認值爲68%；
JDK1.6變爲大約92%；
（2）、"Concurrent Mode Failure"失敗
如果CMS預留內存空間無法滿足程序需要，就會出現一次"Concurrent Mode Failure"失敗；
這時JVM啓用後備預案：臨時啓用Serail Old收集器，而導致另一次Full GC的產生；
這樣的代價是很大的，所以CMSInitiatingOccupancyFraction不能設置得太大。
（C）、產生大量內存碎片
由於CMS基於"標記-清除"算法，清除後不進行壓縮操作；
前面《Java虛擬機垃圾回收(二) 垃圾回收算法》"標記-清除"算法介紹時曾說過：
產生大量不連續的內存碎片會導致分配大內存對象時，無法找到足夠的連續內存，從而需要提前觸發另一次Full GC動作。
解決方法：
（1）、"-XX:+UseCMSCompactAtFullCollection"
使得CMS出現上面這種情況時不進行Full GC，而開啓內存碎片的合併整理過程；
但合併整理過程無法併發，停頓時間會變長；
默認開啓（但不會進行，結合下面的CMSFullGCsBeforeCompaction）；
（2）、"-XX:+CMSFullGCsBeforeCompaction"
設置執行多少次不壓縮的Full GC後，來一次壓縮整理；
爲減少合併整理過程的停頓時間；
默認爲0，也就是說每次都執行Full GC，不會進行壓縮整理；
由於空間不再連續，CMS需要使用可用"空閒列表"內存分配方式，這比簡單實用"碰撞指針"分配內存消耗大；
更多關於內存分配方式請參考：《Java對象在Java虛擬機中的創建過程》
總體來看，與Parallel Old垃圾收集器相比，CMS減少了執行老年代垃圾收集時應用暫停的時間；
但卻增加了新生代垃圾收集時應用暫停的時間、降低了吞吐量而且需要佔用更大的堆空間；
更多CMS收集器信息請參考：
《垃圾收集調優指南》 8節 Concurrent Mark Sweep (CMS) Collector：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector
《內存管理白皮書》 4.6節 Concurrent Mark-Sweep (CMS) Collector：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
8、G1收集器
G1（Garbage-First）是JDK7-u4才推出商用的收集器；
1、特點
（A）、並行與併發
能充分利用多CPU、多核環境下的硬件優勢；
可以並行來縮短"Stop The World"停頓時間；
也可以併發讓垃圾收集與用戶程序同時進行；
（B）、分代收集，收集範圍包括新生代和老年代
能獨立管理整個GC堆（新生代和老年代），而不需要與其他收集器搭配；
能夠採用不同方式處理不同時期的對象；
雖然保留分代概念，但Java堆的內存佈局有很大差別；
將整個堆劃分爲多個大小相等的獨立區域（Region）；
新生代和老年代不再是物理隔離，它們都是一部分Region（不需要連續）的集合；
更多G1內存佈局信息請參考：
《垃圾收集調優指南》 9節：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection
（C）、結合多種垃圾收集算法，空間整合，不產生碎片
從整體看，是基於標記-整理算法；
從局部（兩個Region間）看，是基於複製算法；
這是一種類似火車算法的實現；
都不會產生內存碎片，有利於長時間運行；
（D）、可預測的停頓：低停頓的同時實現高吞吐量
G1除了追求低停頓處，還能建立可預測的停頓時間模型；
可以明確指定M毫秒時間片內，垃圾收集消耗的時間不超過N毫秒；
2、應用場景
面向服務端應用，針對具有大內存、多處理器的機器；
最主要的應用是爲需要低GC延遲，並具有大堆的應用程序提供解決方案；
如：在堆大小約6GB或更大時，可預測的暫停時間可以低於0.5秒；
用來替換掉JDK1.5中的CMS收集器；
在下面的情況時，使用G1可能比CMS好：
（1）、超過50％的Java堆被活動數據佔用；
（2）、對象分配頻率或年代提升頻率變化很大；
（3）、GC停頓時間過長（長於0.5至1秒）。
是否一定採用G1呢？也未必：
如果現在採用的收集器沒有出現問題，不用急着去選擇G1；
如果應用程序追求低停頓，可以嘗試選擇G1；
是否代替CMS需要實際場景測試才知道。
3、設置參數
"-XX:+UseG1GC"：指定使用G1收集器；
"-XX:InitiatingHeapOccupancyPercent"：當整個Java堆的佔用率達到參數值時，開始併發標記階段；默認爲45；
"-XX:MaxGCPauseMillis"：爲G1設置暫停時間目標，默認值爲200毫秒；
"-XX:G1HeapRegionSize"：設置每個Region大小，範圍1MB到32MB；目標是在最小Java堆時可以擁有約2048個Region；
更多關於G1參數設置請參考：
《垃圾收集調優指南》 10.5節：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#important_defaults
4、爲什麼G1收集器可以實現可預測的停頓
G1可以建立可預測的停頓時間模型，是因爲：
可以有計劃地避免在Java堆的進行全區域的垃圾收集；
G1跟蹤各個Region獲得其收集價值大小，在後臺維護一個優先列表；
每次根據允許的收集時間，優先回收價值最大的Region（名稱Garbage-First的由來）；
這就保證了在有限的時間內可以獲取儘可能高的收集效率；
5、一個對象被不同區域引用的問題
一個Region不可能是孤立的，一個Region中的對象可能被其他任意Region中對象引用，判斷對象存活時，是否需要掃描整個Java堆才能保證準確？
在其他的分代收集器，也存在這樣的問題（而G1更突出）：
回收新生代也不得不同時掃描老年代？
這樣的話會降低Minor GC的效率；
解決方法：
無論G1還是其他分代收集器，JVM都是使用Remembered Set來避免全局掃描：
每個Region都有一個對應的Remembered Set；
每次Reference類型數據寫操作時，都會產生一個Write Barrier暫時中斷操作；
然後檢查將要寫入的引用指向的對象是否和該Reference類型數據在不同的Region（其他收集器：檢查老年代對象是否引用了新生代對象）；
如果不同，通過CardTable把相關引用信息記錄到引用指向對象的所在Region對應的Remembered Set中；
當進行垃圾收集時，在GC根節點的枚舉範圍加入Remembered Set；
就可以保證不進行全局掃描，也不會有遺漏。
6、G1收集器運作過程
不計算維護Remembered Set的操作，可以分爲4個步驟（與CMS較爲相似）。
（A）、初始標記（Initial Marking）
僅標記一下GC Roots能直接關聯到的對象；
且修改TAMS（Next Top at Mark Start）,讓下一階段併發運行時，用戶程序能在正確可用的Region中創建新對象；
需要"Stop The World"，但速度很快；
（B）、併發標記（Concurrent Marking）
進行GC Roots Tracing的過程；
剛纔產生的集合中標記出存活對象；
耗時較長，但應用程序也在運行；
並不能保證可以標記出所有的存活對象；
（C）、最終標記（Final Marking）
爲了修正併發標記期間因用戶程序繼續運作而導致標記變動的那一部分對象的標記記錄；
上一階段對象的變化記錄在線程的Remembered Set Log；
這裏把Remembered Set Log合併到Remembered Set中；
需要"Stop The World"，且停頓時間比初始標記稍長，但遠比並發標記短；
採用多線程並行執行來提升效率；
（D）、篩選回收（Live Data Counting and Evacuation）
首先排序各個Region的回收價值和成本；
然後根據用戶期望的GC停頓時間來制定回收計劃；
最後按計劃回收一些價值高的Region中垃圾對象；
回收時採用"複製"算法，從一個或多個Region複製存活對象到堆上的另一個空的Region，並且在此過程中壓縮和釋放內存；
可以併發進行，降低停頓時間，並增加吞吐量；
G1收集器運行示意圖如下：
更多G1收集器信息請參考：
《垃圾收集調優指南》 9節 Garbage-First Garbage Collector：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection
《垃圾收集調優指南》 10節 Garbage-First Garbage Collector Tuning：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#g1_gc_tuning
到這裏，我們大體瞭解HotSpot虛擬機中的所有垃圾收集器，後面我們將去了解JVM的一些內存分配與回收策略、JVM垃圾收集相關調優方法……
【參考資料】
1、《編譯原理》第二版 第7章
2、《深入理解Java虛擬機：JVM高級特性與最佳實踐》第二版 第3章
3、《The Java Virtual Machine Specification》Java SE 8 Edition：https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
4、《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html
5、《Memory Management in the Java HotSpot™ Virtual Machine》：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
6、HotSpot虛擬機參數官方說明：http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
7、《Thinking in Java》第四版 5.5 清理：終結處理和垃圾回收；