CMS收集器調節

重點當然是要調節CMS收集器，即要避免它在收集時停頓過長，更要避免產生promotion failed和concurrent mode failure的情況，因為這兩種情況發生后都會引起CMS做Stop-The-World GC，其中第二中情況在做GC時還會做整理（Compact），因而會有更久的停頓，而我們這次是兩種情況同時遇到了。要避免這兩種情況的發生需要先理解為什么會發生這兩種情況。

首先，我們來看看promotion failed發生的情況：
我們知道當對象到一定的年齡，或者在某次回收過程中一個Survivor無法裝下所有存活的對象，或者一個對象的大小超過-XX:PretenureSizeThreshold設置的值，就會被promote到Old Gen中，而在promote過程中如果Old Gen無法裝下所有的內存時就會產生promotion failed（這里說CMS是根據預估的值：Modern CMS collector estimates size of objects to be promoted using statistics from previous collections. If old space does not have enough free bytes to hold estimated promotion amount, concurrent mode failure will be raise.但是我的理解是這是ParNew做的GC，為什么由CMS來預估？所以應該是ParNew把需要promote的對象傳遞給CMS，然后CMS做預估決定是否有足夠多的內存存放這些新promote的對象），此時就會先做一遍CMS GC，然后將新promote的對象存放到Old Gen中，由于這屬于ParNew GC的范圍，因而這次的CMS GC依然處于STW狀態，因而這會花比較久的時間。如這次的ParNew GC，花費5.75s：
2015-07-20T08:23:00.028-0400: [GC [ParNew (promotion failed): 844305K->841244K(943744K), 0.2358120 secs][CMS: 6282619K->1891959K(9437184K), 5.5098940 secs] 7126660K->1891959K(10380928K), [CMS Perm : 67716K->66078K(112860K)], 5.7458460 secs] [Times: user=4.77 sys=0.02, real=5.75 secs]

我們當前的設置：-XX:CMSInitiatingOccupancyFraction=79 -XX:+UseCMSInitiatingOccupancyOnly，也就是只有到Old Gen占用79%后才會觸發CMS GC，這里只占66.57%，因而還沒能觸發CMS GC，然而此時ParNew GC只回收了3061K的對象，還有841244K的對象存活，而一個Survivor只有104857.6K大小，此時需要promote大概736386.4K大小的數據到Old Gen中，此時Old Gen還有（9437184K-6282619K=3154565K）大小的內存，雖然遠遠大于被promote的對象，但是我們知道CMS采用標記-清除（Mark-Sweep）算法，而不主動整理（Compact），但是它在每次回收時會合并相鄰的內存空間，然而跑久了難免會產生內存碎片，也就是說此時內存碎片已經很多了，無法容納新promote的對象，要不就是新promote的對象大小太大，或者碎片太小，因而需要出發一次CMS GC來釋放一些空間（此時發生的CMS是不是已經退化成Serial Old收集器算法了？即在收集的過程還是整理？），以保證能存放下所有新promote出的對象。這里GC日志中并沒有顯示出什么這次ParNew GC后，Young Gen還剩下多少內存，但是根據下一次ParNew GC的初始大小是838912K，小于之前存活下來的對象（841244K），因而我們可以確定這次GC的結果是把多余的對象promtoe到Old Gen中了。
所以根據分析，我們可以從兩個方向調節參數：
1. 降低CMS GC的閾值。
2. 提前減少Old Gen中的碎片，即讓CMS GC做整理。
對降低CMS GC閾值，我們可以調節參數：-XX:CMSInitiatingOccupancyFraction，默認大小68，我們可以將它設置成60。對提前減少Old Gen的碎片，這個比較麻煩，我們不想每次CMS GC都做整理（Compact），因而這會比較浪費，會增加GC總體的時間以及停頓的時間，而且也比較危險，因為萬一某次整理時間太長會引起集群的不穩定（可以設置-XX:UseCMSCompactAtFullCollection來實現這個功能）。還有一種辦法是設置每經歷N次CMS后做一次整理，通過-XX:CMSFullGCsBeforeCompaction=<N>來設置，這個相對可以接受一些。當然如果能找到一個相對空閑的時間手動觸發一次Full GC，并且確保讓它能觸發整理（這個目前還沒有找到合適的方法，JConsole提供的GC按鈕是一個可選項，但是不確定。我做了一下嘗試：

2015-07-31T16:04:49.183+0800: [Full GC (System) [CMS: 3861443K->1072505K(9437184K), 2.9535440 secs] 4458634K->1072505K(10380928K), [CMS Perm : 68183K->67112K(112880K)], 2.9537000 secs] [Times: user=2.94 sys=0.00, real=2.95 secs]
看起來是減少了不少內存，按日志的格式，看起來像是Serial Old的算法？另外，使用這個功能要確保-XX:-DisableExplicitGC是關閉的，雖然這就是默認值）。

關于產生promotion failed，這里還有更詳細的解釋，如涉及到PLAB（Promotion Local Allocation Buffer）的介紹等，以及這里是對它的更正。值得注意的是，CMS在管理內存中使用空閑列表的方式，然而這種方式可能會存在某些問題，如這句話所說（具體就不展開了）：
CMS memory manager is using separate free lists for different size of chunks. Using these free lists, it can effectively fill small holes in fragmented memory space with objects of exact size. This technique is known to be fairly effective (and widely used in C/C++ memory managers). But, surprisingly, it doesn't seems to work well for JVM in many real live situations.

然后，再來看看concurrent mode failure的情況：
依然是這篇文章，作者說concurrent mode failure是在Young GC發生前，它會預估Old Gen是否有足夠的空間存放從Young Gen中promote上來的對象，CMS收集器根據之前統計來預估這些對象的大小，如果Old Gen沒有足夠的空間存放這個預估的值，就會發生concurrent mode failure。此時不一定會產生Full GC，有些時候JVM只是等待當前并行收集完成，但是用戶程序此時還是會STW直到這次收集技術。
At beginning  of each young GC, collector should ensure that there is enough free memory in old space to promote aged objects from young space. Modern CMS collector estimates size of objects to be promoted using statistics from previous collections. If old space does not have enough free bytes to hold estimated promotion amount, concurrent mode failure will be raise. Concurrent mode failure doesn't necessary lead to Full GC, in certain cases JVM will just wait for concurrent collection cycle to finish, but application will remain in STW pause until young collection will be finished.

然而根據我的觀察，concurrent mode failure都是發生在CMS已經開始，但是在中間階段，出現ParNew的promotion failed。
如這是發生在CMS-concurrent-abortable-preclean階段：

這是發生在CMS-concurrent-sweep階段：

這是發生在CMS-concurrent-mark階段：

雖然分析了那么多，還有一個疑問沒能解決，對這個問題的調節方法還是一樣的：1. 降低CMS GC的閾值；2. 提前減少Old Gen中的碎片，即讓CMS GC做整理。這里不再贅述。

最后，我們可以看看其他的調節方式：
1. 我們知道CMS收集器很多過程是并發進行的，因而我們可以控制并發線程的個數：-XX:ParallelCMSThreads=4，我們采用的值是4，和ParNew相同。CMS默認的回收線程數是(CPU個數+3)/4。
2. 在歷史上還出現過增量式并發收集器（Incremental Concurrent Mark Sweep，i-CMS）。因為對少于4個CPU的時候，如果GC占用一般左右的CPU資源，會影響用戶線程的吞吐量，因而增量式并發收集器的思想是在并發標記和并發清理時讓用戶線程和GC線程交替運行以減少GC占用太多的資源，特別是在只有一個CPU的情況下，即使在CMS并發階段，還是會產生STW的現象，因而可以使用i-CMS來避免這種情況。然而i-CMS已經不再推薦使用，具體可以參考這里。大概的原因是現在已經很少只有一個CPU的硬件了，而且i-CMS在線程切換時會花費更多的資源和時間，它更加復雜，有更多的參數，難以調節，會產生更多的碎片。

3. 可以簡單介紹一下CMS的整個過程（還可以參考這里，或者這里，雖然這里用的例子是1.4.2的版本，我用的是1.6.30，會有一些區別）。以一個正常的CMS為例：

1 CMS-initial-mark：初始標記標記階段，STW，CMS起始點，標記所有Root對象直接可達的對象，7462216K是CMS觸發時Old Gen的內存大小，7583692K是Old Gen＋Young Gen的內存大小。
CMS-concurrent-mark：重新標記階段，和用戶線程同時處理，遍歷初始標記出來的對象的所有直接或間接可達對象。CPU時間0.365s，總共0.365s（wall time）。這里times時間不是那么準確，因為起于該階段的開始，但是中間可能包含其他的事情，如用戶線程的執行影響等。

CMS-concurrent-preclean：preclean階段，這個階段依然和用戶線程同時處理，它會繼續查看在重新標記階段新產生的對象：從Young Gen promote上來的對象，新分配的對象，或被修改的對象。這個階段主要用于減少下一次重新標記（remark）的時間，因為重新標記會STW。CPU時間0.020s，總共0.020s（wall time）。
CMS-concurrent-abortable-preclean：可中斷的preclean階段，和用戶線程同時處理，當preclean已經結束的時候就可以開始remark了，然而如果這樣設計，由于CMS-concurrent-preclean和用戶線程一起運行，當它結束的時候，Young Gen已經使用了很多了，但是這里面有很多是可以回收的，為了提升效率就可以先ParNew GC回收掉多余的對象，然后就會接著執行remark，就可以減少remark的時間；而如果Young Gen使用的很少，就可以立即啟動remark過程；而如果介于之間，就可以先等待一會讓eden占用一些空間后再啟動remark，從而將ParNew GC的STW和remark的STW錯分開。因而CMS的設計者就想出remark的執行時機還依賴于eden的使用情況（因為新對象總是先分配到eden空間），即通過兩個變量來控制：CMSScheduleRemarkEdenSize和CMSScheduleRemarkEdenPenetration，它們的默認值分別是2M和50%，表示在CMS-concurrent-preclean結束后，如果eden只使用了少于2M，則直接啟動remark；如果超過2M，但沒有超過50%，則先啟動CMS-concurrent-abortable-preclean，直到eden的使用率超過了50%，然后啟動remark過程，這樣就保證了remark和ParNew GC中間會有一定的時間間隔；如果已經超過了50%，就等待下次ParNew GC完成，然后再做remark？貌似只有這樣才能解釋的通這些日志，當remark階段準備好后它可以隨時被中斷，它的中斷不是錯。如這種日志：

這個日志表示preclean結束后eden使用少于2M，因而跳過abortable-preclean，直接開始remark階段。

1 CMS-remark：重新標記階段，STW，這里YG occupancy表示該階段開始時Young Gen的大小，因為這個階段的時間長短部分依賴于Young Gen的大小；Rescan用于多線程掃描程序停止時存活的對象，花費0.1319540s；weak refs processing用于處理weak reference的情況，花費0.0001s，如果這個階段花費太長時間，可以打開開關：-XX:+ParallelRefProcEnabled來調節；然后開始重新標記，即重新從Root對象遍歷標記存活對象。
CMS-concurrent-sweep：并發清理，和其他線程同時執行，做真正的清理工作，如把可以回收的內存放回空閑列表，合并相鄰內存空間等。

CMS-concurrent-reset：重置CMS的狀態用于下一次執行。