https://www.ziwenxie.site/2017/07/24/java-jvm-gc/
引言
本文主要講述JVM中幾種常見的垃圾回收算法和相關(guān)的垃圾回收器，以及常見的和GC相關(guān)的性能調(diào)優(yōu)參數(shù)。
JVM系列文章
GC Roots
我們先來了解一下在Java中是如何判斷一個對象的生死的，有些語言比如Python是采用引用計數(shù)來統(tǒng)計的，但是這種做法可能會遇見循環(huán)引用的問題，在Java以及C#等語言中是采用GC Roots來解決這個問題。如果一個對象和GC Roots之間沒有鏈接，那么這個對象也可以被視作是一個可回收的對象。
Java中可以被作為GC Roots中的對象有：
- 虛擬機棧中的引用的對象。
- 方法區(qū)中的類靜態(tài)屬性引用的對象。
- 方法區(qū)中的常量引用的對象。
- 本地方法棧（jni）即一般說的Native的引用對象。
標記清除
標記-清除算法將垃圾回收分為兩個階段：標記階段和清除階段。在標記階段首先通過根節(jié)點，標記所有從根節(jié)點開始的對象，未被標記的對象就是未被引用的垃圾對象。然后，在清除階段，清除所有未被標記的對象。標記清除算法帶來的一個問題是會存在大量的空間碎片，因為回收后的空間是不連續(xù)的，這樣給大對象分配內(nèi)存的時候可能會提前觸發(fā)full gc。
[圖片上傳中...(image-1636c3-1512976129104-2)]
標記清除
復制算法
將現(xiàn)有的內(nèi)存空間分為兩快，每次只使用其中一塊，在垃圾回收時將正在使用的內(nèi)存中的存活對象復制到未被使用的內(nèi)存塊中，之后，清除正在使用的內(nèi)存塊中的所有對象，交換兩個內(nèi)存的角色，完成垃圾回收。
[圖片上傳中...(image-c08f70-1512976129104-1)]
復制算法
現(xiàn)在的商業(yè)虛擬機都采用這種收集算法來回收新生代，IBM研究表明新生代中的對象98%是朝夕生死的，所以并不需要按照1:1的比例劃分內(nèi)存空間，而是將內(nèi)存分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中的一塊Survivor。當回收時，將Eden和Survivor中還存活著的對象一次性地拷貝到另外一個Survivor空間上，最后清理掉Eden和剛才用過的Survivor的空間。HotSpot虛擬機默認Eden和Survivor的大小比例是8:1(可以通過-SurvivorRattio來配置)，也就是每次新生代中可用內(nèi)存空間為整個新生代容量的90%，只有10%的內(nèi)存會被“浪費”。當然，98%的對象可回收只是一般場景下的數(shù)據(jù)，我們沒有辦法保證回收都只有不多于10%的對象存活，當Survivor空間不夠用時，需要依賴其他內(nèi)存（這里指老年代）進行分配擔保。
標記整理
復制算法的高效性是建立在存活對象少、垃圾對象多的前提下的。這種情況在新生代經(jīng)常發(fā)生，但是在老年代更常見的情況是大部分對象都是存活對象。如果依然使用復制算法，由于存活的對象較多，復制的成本也將很高。
[圖片上傳中...(image-2b049f-1512976129104-0)]
標記整理
標記-壓縮算法是一種老年代的回收算法，它在標記-清除算法的基礎上做了一些優(yōu)化。首先也需要從根節(jié)點開始對所有可達對象做一次標記，但之后，它并不簡單地清理未標記的對象，而是將所有的存活對象壓縮到內(nèi)存的一端。之后，清理邊界外所有的空間。這種方法既避免了碎片的產(chǎn)生，又不需要兩塊相同的內(nèi)存空間，因此，其性價比比較高。
增量算法
增量算法的基本思想是，如果一次性將所有的垃圾進行處理，需要造成系統(tǒng)長時間的停頓，那么就可以讓垃圾收集線程和應用程序線程交替執(zhí)行。每次，垃圾收集線程只收集一小片區(qū)域的內(nèi)存空間，接著切換到應用程序線程。依次反復，直到垃圾收集完成。使用這種方式，由于在垃圾回收過程中，間斷性地還執(zhí)行了應用程序代碼，所以能減少系統(tǒng)的停頓時間。但是，因為線程切換和上下文轉(zhuǎn)換的消耗，會使得垃圾回收的總體成本上升，造成系統(tǒng)吞吐量的下降。
垃圾回收器
Serial收集器
Serial收集器是最古老的收集器，它的缺點是當Serial收集器想進行垃圾回收的時候，必須暫停用戶的所有進程，即stop the world。到現(xiàn)在為止，它依然是虛擬機運行在client模式下的默認新生代收集器，與其他收集器相比，對于限定在單個CPU的運行環(huán)境來說，Serial收集器由于沒有線程交互的開銷，專心做垃圾回收自然可以獲得最高的單線程收集效率。
Serial Old是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用”標記－整理“算法。這個收集器的主要意義也是被Client模式下的虛擬機使用。在Server模式下，它主要還有兩大用途：一個是在JDK1.5及以前的版本中與Parallel Scanvenge收集器搭配使用，另外一個就是作為CMS收集器的后備預案，在并發(fā)收集發(fā)生Concurrent Mode Failure的時候使用。
通過指定-UseSerialGC參數(shù)，使用Serial + Serial Old的串行收集器組合進行內(nèi)存回收。
ParNew收集器
ParNew收集器是Serial收集器新生代的多線程實現(xiàn)，注意在進行垃圾回收的時候依然會stop the world，只是相比較Serial收集器而言它會運行多條進程進行垃圾回收。
ParNew收集器在單CPU的環(huán)境中絕對不會有比Serial收集器更好的效果，甚至由于存在線程交互的開銷，該收集器在通過超線程技術(shù)實現(xiàn)的兩個CPU的環(huán)境中都不能百分之百的保證能超越Serial收集器。當然，隨著可以使用的CPU的數(shù)量增加，它對于GC時系統(tǒng)資源的利用還是很有好處的。它默認開啟的收集線程數(shù)與CPU的數(shù)量相同，在CPU非常多（譬如32個，現(xiàn)在CPU動輒4核加超線程，服務器超過32個邏輯CPU的情況越來越多了）的環(huán)境下，可以使用-XX:ParallelGCThreads參數(shù)來限制垃圾收集的線程數(shù)。
-UseParNewGC: 打開此開關(guān)后，使用ParNew + Serial Old的收集器組合進行內(nèi)存回收，這樣新生代使用并行收集器，老年代使用串行收集器。
Parallel Scavenge收集器
Parallel是采用復制算法的多線程新生代垃圾回收器，似乎和ParNew收集器有很多的相似的地方。但是Parallel Scanvenge收集器的一個特點是它所關(guān)注的目標是吞吐量(Throughput)。所謂吞吐量就是CPU用于運行用戶代碼的時間與CPU總消耗時間的比值，即吞吐量=運行用戶代碼時間 / (運行用戶代碼時間 + 垃圾收集時間)。停頓時間越短就越適合需要與用戶交互的程序，良好的響應速度能夠提升用戶的體驗；而高吞吐量則可以最高效率地利用CPU時間，盡快地完成程序的運算任務，主要適合在后臺運算而不需要太多交互的任務。
Parallel Old收集器是Parallel Scavenge收集器的老年代版本，采用多線程和”標記－整理”算法。這個收集器是在jdk1.6中才開始提供的，在此之前，新生代的Parallel Scavenge收集器一直處于比較尷尬的狀態(tài)。原因是如果新生代Parallel Scavenge收集器，那么老年代除了Serial Old(PS MarkSweep)收集器外別無選擇。由于單線程的老年代Serial Old收集器在服務端應用性能上的”拖累“，即使使用了Parallel Scavenge收集器也未必能在整體應用上獲得吞吐量最大化的效果，又因為老年代收集中無法充分利用服務器多CPU的處理能力，在老年代很大而且硬件比較高級的環(huán)境中，這種組合的吞吐量甚至還不一定有ParNew加CMS的組合”給力“。直到Parallel Old收集器出現(xiàn)后，”吞吐量優(yōu)先“收集器終于有了比較名副其實的應用，在注重吞吐量及CPU資源敏感的場合，都可以優(yōu)先考慮Parallel Scavenge加Parallel Old收集器。
-UseParallelGC: 虛擬機運行在Server模式下的默認值，打開此開關(guān)后，使用Parallel Scavenge + Serial Old的收集器組合進行內(nèi)存回收。-UseParallelOldGC: 打開此開關(guān)后，使用Parallel Scavenge + Parallel Old的收集器組合進行垃圾回收
CMS收集器
CMS(Concurrent Mark Swep)收集器是一個比較重要的回收器，現(xiàn)在應用非常廣泛，我們重點來看一下，CMS一種獲取最短回收停頓時間為目標的收集器，這使得它很適合用于和用戶交互的業(yè)務。從名字(Mark Swep)就可以看出，CMS收集器是基于標記清除算法實現(xiàn)的。它的收集過程分為四個步驟：
- 初始標記(initial mark)
- 并發(fā)標記(concurrent mark)
- 重新標記(remark)
- 并發(fā)清除(concurrent sweep)
注意初始標記和重新標記還是會stop the world，但是在耗費時間更長的并發(fā)標記和并發(fā)清除兩個階段都可以和用戶進程同時工作。
不過由于CMS收集器是基于標記清除算法實現(xiàn)的，會導致有大量的空間碎片產(chǎn)生，在為大對象分配內(nèi)存的時候，往往會出現(xiàn)老年代還有很大的空間剩余，但是無法找到足夠大的連續(xù)空間來分配當前對象，不得不提前開啟一次Full GC。為了解決這個問題，CMS收集器默認提供了一個-XX:+UseCMSCompactAtFullCollection收集開關(guān)參數(shù)（默認就是開啟的)，用于在CMS收集器進行FullGC完開啟內(nèi)存碎片的合并整理過程，內(nèi)存整理的過程是無法并發(fā)的，這樣內(nèi)存碎片問題倒是沒有了，不過停頓時間不得不變長。虛擬機設計者還提供了另外一個參數(shù)-XX:CMSFullGCsBeforeCompaction參數(shù)用于設置執(zhí)行多少次不壓縮的FULL GC后跟著來一次帶壓縮的（默認值為0，表示每次進入Full GC時都進行碎片整理）。
不幸的是，它作為老年代的收集器，卻無法與jdk1.4中已經(jīng)存在的新生代收集器Parallel Scavenge配合工作，所以在jdk1.5中使用cms來收集老年代的時候，新生代只能選擇ParNew或Serial收集器中的一個。ParNew收集器是使用-XX:+UseConcMarkSweepGC選項啟用CMS收集器之后的默認新生代收集器，也可以使用-XX:+UseParNewGC選項來強制指定它。
由于CMS收集器現(xiàn)在比較常用，下面我們再額外了解一下CMS算法的幾個常用參數(shù)：
- UseCMSInitatingOccupancyOnly：表示只在到達閾值的時候，才進行 CMS 回收。
- CMS默認啟動的回收線程數(shù)目是(ParallelGCThreads+3)/4，如果你需要明確設定，可以通過-XX:+ParallelCMSThreads來設定，其中-XX:+ParallelGCThreads代表的年輕代的并發(fā)收集線程數(shù)目。
- CMSClassUnloadingEnabled： 允許對元類數(shù)據(jù)進行回收。
- CMSInitatingPermOccupancyFraction：當永久區(qū)占用率達到這一百分比后，啟動 CMS 回收 (前提是-XX:+CMSClassUnloadingEnabled 激活了)。
- CMSIncrementalMode：使用增量模式，比較適合單 CPU。
- UseCMSCompactAtFullCollection參數(shù)可以使 CMS 在垃圾收集完成后，進行一次內(nèi)存碎片整理。內(nèi)存碎片的整理并不是并發(fā)進行的。
- UseFullGCsBeforeCompaction：設定進行多少次 CMS 垃圾回收后，進行一次內(nèi)存壓縮。
一些建議
對于Native Memory:
- 使用了NIO或者NIO框架（Mina/Netty）
- 使用了DirectByteBuffer分配字節(jié)緩沖區(qū)
- 使用了MappedByteBuffer做內(nèi)存映射
- 由于Native Memory只能通過FullGC回收，所以除非你非常清楚這時真的有必要，否則不要輕易調(diào)用System.gc()。
另外為了防止某些框架中的System.gc調(diào)用（例如NIO框架、Java RMI），建議在啟動參數(shù)中加上-XX:+DisableExplicitGC來禁用顯式GC。這個參數(shù)有個巨大的坑，如果你禁用了System.gc()，那么上面的3種場景下的內(nèi)存就無法回收，可能造成OOM，如果你使用了CMS GC，那么可以用這個參數(shù)替代：-XX:+ExplicitGCInvokesConcurrent。
此外除了CMS的GC，其實其他針對old gen的回收器都會在對old gen回收的同時回收young gen。
G1收集器
G1收集器是一款面向服務端應用的垃圾收集器。HotSpot團隊賦予它的使命是在未來替換掉JDK1.5中發(fā)布的CMS收集器。與其他GC收集器相比，G1具備如下特點：
- 并行與并發(fā)：G1能更充分的利用CPU，多核環(huán)境下的硬件優(yōu)勢來縮短stop the world的停頓時間。
- 分代收集：和其他收集器一樣，分代的概念在G1中依然存在，不過G1不需要其他的垃圾回收器的配合就可以獨自管理整個GC堆。
- 空間整合：G1收集器有利于程序長時間運行，分配大對象時不會無法得到連續(xù)的空間而提前觸發(fā)一次GC。
可預測的非停頓：這是G1相對于CMS的另一大優(yōu)勢，降低停頓時間是G1和CMS共同的關(guān)注點，能讓使用者明確指定在一個長度為M毫秒的時間片段內(nèi)，消耗在垃圾收集上的時間不得超過N毫秒。 - 在使用G1收集器時，Java堆的內(nèi)存布局和其他收集器有很大的差別，它將這個Java堆分為多個大小相等的獨立區(qū)域，雖然還保留新生代和老年代的概念，但是新生代和老年代不再是物理隔離的了，它們都是一部分Region（不需要連續(xù)）的集合。
雖然G1看起來有很多優(yōu)點，實際上CMS還是主流。
與GC相關(guān)的常用參數(shù)
除了上面提及的一些參數(shù)，下面補充一些和GC相關(guān)的常用參數(shù)：
- Xmx: 設置堆內(nèi)存的最大值。
- Xms: 設置堆內(nèi)存的初始值。
- Xmn: 設置新生代的大小。
- Xss: 設置棧的大小。
- PretenureSizeThreshold: 直接晉升到老年代的對象大小，設置這個參數(shù)后，大于這個參數(shù)的對象將直接在老年代分配。
- MaxTenuringThrehold: 晉升到老年代的對象年齡。每個對象在堅持過一次Minor GC之后，年齡就會加1，當超過這個參數(shù)值時就進入老年代。
- UseAdaptiveSizePolicy: 在這種模式下，新生代的大小、eden 和 survivor 的比例、晉升老年代的對象年齡等參數(shù)會被自動調(diào)整，以達到在堆大小、吞吐量和停頓時間之間的平衡點。在手工調(diào)優(yōu)比較困難的場合，可以直接使用這種自適應的方式，僅指定虛擬機的最大堆、目標的吞吐量 (GCTimeRatio) 和停頓時間 (MaxGCPauseMills)，讓虛擬機自己完成調(diào)優(yōu)工作。
- SurvivorRattio: 新生代Eden區(qū)域與Survivor區(qū)域的容量比值，默認為8，代表Eden: Suvivor= 8: 1。
- XX:ParallelGCThreads：設置用于垃圾回收的線程數(shù)。通常情況下可以和 CPU 數(shù)量相等。但在 CPU 數(shù)量比較多的情況下，設置相對較小的數(shù)值也是合理的。
- XX:MaxGCPauseMills：設置最大垃圾收集停頓時間。它的值是一個大于 0 的整數(shù)。收集器在工作時，會調(diào)整 Java 堆大小或者其他一些參數(shù)，盡可能地把停頓時間控制在 MaxGCPauseMills 以內(nèi)。
- XX:GCTimeRatio:設置吞吐量大小，它的值是一個 0-100 之間的整數(shù)。假設 GCTimeRatio 的值為 n，那么系統(tǒng)將花費不超過 1/(1+n) 的時間用于垃圾收集。
