最近時間比較緊張，要寫的東西也有很多，只能想到一點寫一點。關於GC，網上的資料太多，之前對一個系統調優的時候又回顧了一下，找了幾篇廣泛流傳的資料，大部分都是大同小異，這裡總個總結，希望能夠做個相對的全集，並寫出一些新的點，比如Card Marking（卡片標記）等。

首先是大家都要提到的GC的基礎演算法：標記清除，標記整理，複製，分代。這些演算法的第一步都是做的一件事: 標記(Mark)。

JVM的標記演算法採用了根搜尋演算法(Root Tracing)。根有幾種：

1. JVM棧的Frame裡面的引用

2. 靜態類，常量的引用

3. 本地棧中的引用

4. 本地方法的引用

一般我們能控制的就是JVM棧中的引用和靜態類，常量的引用。標記也分為幾個階段，比如

1. 標記直接和根引用的物件

2. 標記間接和根引用的物件

3. 由於分代演算法，被老年代物件所引用的新生代的物件

對於第三種，JVM採用了Card Marking(卡片標記)的方法，避免了在做Minor GC時需要對整個老年代掃描。具體的方法如下:

1. 將老年代的記憶體分片，1個片預設是512byte

2. 如果老年代的物件發生了修改，就把這個老年代物件所在的片標記為髒 dirty。或者老年代物件指向了新生代物件，那麼它所在的片也會被標記為dirty

3. 沒有標記為髒的老年代片它沒有指向新的新生代物件，所以可以不需要去掃描

4. Minor GC掃描老年代空間時，只需要去掃描髒的卡片的物件，不需要掃描整個老年代空間

所以做Minor GC時標記的時間 = T(stack_scan) + T(card_scan) + T(old_root_scan).

T(stack_scan): 級聯掃描在JVM棧裡的根的時間

T(card_scan): 級聯掃描卡表中髒卡片的時間

T(old_root_scan): 掃描在老年代中的直接的根的時間。注意是直接的根，不會去級聯掃描老年代的物件。因為掃描都是從根開始的，一開始不知道根到底是在老年代還是新生代

和Card Marking相關的一個重要的JVM引數是-XX:UseCondCardMark 。使用這個引數的原因是在高併發的情況下，Card標記為髒的操作本身就存在著競爭，使用這個引數可以避免卡片被重複標記為髒，從而提高效能。

說完了標記，下面提一下幾種基礎的GC演算法，沒有什麼新的點，直接引用網上的圖

標記-清除演算法

複製演算法

標記--整理演算法

分代演算法是將物件分為新生代和老年代，然後使用不同的GC策略來進行回收，提高整體的效率。

由於新生代的大部分物件都會在一次Minor GC中死亡，存活的物件很少，所以新生代的GC收集器都採用了複製演算法。新生代分為Eden + S0 + S1. S0和S1就是用來實現複製的，在任何一次Minor GC後，S0和S1總是隻有一個區域有資料，另一個區域為空，以便於下一次複製使用

當新生代空間不能滿足大物件分配時，老年代空間為它提供了分配擔保，大物件可以直接進入老年代。有兩個JVM引數可以控制新生代進入老年代的門檻:

PretenureSizeThreshold: 單位是B，設定了物件大小的閥值

MaxTenuringThreshold: 設定了進入老年代的年齡的閥值

老年代物件一般都是存活時間久，老年代的空間本來就大，所以沒有更多空間來提供分配擔保，所以老年代一般採用標記--清理或者標記--整理演算法。

下面這張圖很好地介紹了JDK6的各種GC收集器以及各自的特點:

1. 新生代都採用複製演算法

2. CMS採用了標記--清除演算法，由於標記清除演算法會生成記憶體碎片，所以JVM提供了引數來使CMS可以在幾次清除後作一次整理

-XX:CMSFullGCsBeforeCompaction：由於併發收集器不對記憶體空間進行壓縮、整理，所以執行一段時間以後會產生“碎片”，使得執行效率降低。此值設定執行多少次GC以後對記憶體空間進行壓縮、整理。
-XX:+UseCMSCompactAtFullCollection：開啟對年老代的壓縮。可能會影響效能，但是可以消除碎片

3. Serial Old(MSC)和Parallel Old都採用標記整理演算法

4. UseSerialGC預設會在新生代使用Serial收集器，在老年代使用Serial Old收集器，這兩個都是單執行緒的收集器

5. UseConcMarkSweepGC預設會再新生代使用ParNew收集器，這是個併發的收集器。在老年代會使用CMS + Serial Old收集器，當CMS失敗的時候，會啟用Serial Old做FULL GC

6. UseParallelOldGC預設會在新生的使用Parallel Scavenge收集器，在老年代使用Parallel Old收集器。這兩個收集器都是吞吐量優先，所謂吞吐量優先就是它可以嚴格控制GC的時間，從而保證吞吐量。但是吞吐量提高了，新生代和老年代的空間就是動態調整的，而不是按照初始配置的大小。因為單位時間清除的垃圾量近乎一個常量，既然要保證時間，那麼必須保證垃圾總量，而垃圾總量可以通過新生代和老年代的大小來控制的

7. 對於和使用者有互動的應用，比如Web應用，一個重要的考量是系統的響應時間，要保證系統的響應時間就要保證由GC導致的stop the world次數少，或者讓使用者執行緒和GC執行緒一起執行。所以Web應用是使用CMS收集器的一個重要場景。CMS減少了stop the world的次數，不可避免地讓整體GC的時間拉長了。

8. 對於計算密集型的應用可能會考慮計算的吞吐量，這時候可以使用Parallel Scavenge收集器來保證吞吐量

9. Serial, ParNew, Parallel Scanvange, Parallel Old, Serial Old全程都會Stop the world，JVM這時候只執行GC執行緒，不執行使用者執行緒

10. CMS主要分為 initial Mark, Concurrent Mark, ReMark, Concurrent Sweep等階段，initial Mark和Remark佔整體的時間比較較小，它們會Stop the world. Concurrent Mark和Concurrent Sweep會和使用者執行緒一起執行。

下面這張圖對GC的日誌資訊做了說明:

關於JVM調優的各種引數設定，網上一抓一大把，這裡不多說了。有一個調優的整體的原則：

1. 先做一個JVM的效能測試，瞭解當前的狀態

2. 明確調優的目標，比如減少FULL GC的次數，減少GC的總時間，提高吞吐量等

3. 調整引數後再進行多次的測試，分析，最終達到一個較為理想的狀態。各種引數要根據系統的自身情況來確定，沒有統一的解決方案

將各種工具的文章頁很多，這裡從解決問題的角度出發列出幾個。

檢視JVM啟動引數

1. jps -v

2. jinfo -flags pid

3. jinfo pid -- 列出JVM啟動引數和system.properties

4. ps -ef | grep java

檢視當前堆的配置

1. jstat -gc pid 1000 3  -- 列出堆的各個區域的大小

2. jstat -gcutil pid 1000 3 -- 列出堆的各個區域使用的比例

3. jmap -heap pid  -- 列出當前使用的GC演算法，堆的各個區域大小

檢視執行緒的堆疊資訊

1. jstack -l pid 

dump堆內的物件

1. jmap -dump:live,format=b,file=xxx pid

2. -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=xxx  -- 設定JVM引數，當JVM OOM時輸出堆的dump

3. ulimit  -c unlimited  -- 設定Linux ulimit引數，可以產生coredump且不受大小限制。之前在線上遇到過一個極其詭異的問題，JVM整個程序突然掛了，這時候依靠JVM本身生成dump檔案已經不行了，只有依賴Linux，讓系統來生成程序掛掉的core dump檔案

使用jstack 可以來獲得這個coredump的執行緒堆疊資訊:  jstack "$JAVA_HOME/bin/java" core.xxx > core.log

獲得當前系統佔用CPU最高的10個程序，執行緒

ps Hh -eo pid,tid,pcpu,pmem | sort -nk3 |tail > temp.txt

圖形化介面
1. jvisualvm 裡面有很多外掛，比如Visual GC，可以視覺化地看到各個堆區域時候的狀態，從而可以對整體GC的效能有整體的認識

就說到這吧，有遺漏的後面再補充

《深入理解JVM》

《Think in GC》