背景
先說一下基本情況，本次是對線上商品服務(wù)的JVM優(yōu)化。商品服務(wù)的訪問量非常高，單機(jī)QPS在3000左右，線上總共部署了15個商品服務(wù)節(jié)點。JVM堆內(nèi)存大小是8G，其中給新生代分配了2G，老年代垃圾回收器采用CMS，新生代垃圾回收器是ParNew。
優(yōu)化前的情況
首先我們使用 jstat 查看了 GC 的情況。又通過查看GC log，分析了GC 的詳細(xì)狀況。
使用 jstat -gcutil ${pid} 1000 每隔一秒打印一次 GC 統(tǒng)計信息。
可以看到，單次 Young GC 平均耗時是 60ms 左右，還是不錯的，但是Young GC（YGC ）非常頻繁，基本上每秒一次，有時還會一秒兩次，在一秒兩次的時候，Young GC對系統(tǒng)響應(yīng)的壓力就會比較明顯。
jstat相關(guān)指標(biāo)說明：
YGCT：Young GC 總時間，單位為秒
YGC：Young GC 次數(shù)
FGCT：Full GC 總時間，單位為秒
FGC：Full GC 次數(shù)
GCT：GC 總時間，是 YGCT 和 FGCT 之和
接著查看 GC log，打印 GC log 需要在 JVM 啟動參數(shù)里添加如下參數(shù)：
-XX:+PrintGCDateStamps：打印 GC 發(fā)生的時間戳。
-XX:+PrintTenuringDistribution：打印 GC 發(fā)生時的代齡信息。
-XX:+PrintGCApplicationStoppedTime：打印 GC 停頓時長
-XX:+PrintGCApplicationConcurrentTime：打印 GC 間隔的服務(wù)運(yùn)行時長
-XX:+PrintGCDetails：打印 GC 詳情，包括 GC 前/內(nèi)存等。
-Xloggc:…/gclogs/gc.log.date：指定 GC log 的路徑
GC log如下：
從Log中，我們可以看到 gc 前有很多次 18ms 左右的停頓。
進(jìn)一步分析和優(yōu)化
直接查看 GC log 不太直觀，可以借助一些可視化JVM分析工具來幫助我們分析，推薦一款不錯的在線分析工具GCeasy，我們把 GC log 上傳到https://gceasy.io 后， GCeasy 會根據(jù)GC log生成各個維度的圖表，讓我們更直觀的分析JVM問題。
通過查看 GCeasy 生成的圖表，我們可以發(fā)現(xiàn)JVM的吞吐量是 93%，即 JVM 運(yùn)行業(yè)務(wù)代碼的時長占 JVM 總運(yùn)行時長的93%，這個吞吐量確實比較低，運(yùn)行 100 分鐘就有 7 分鐘在執(zhí)行 GC 操作。幸好這些 GC 中絕大多數(shù)都是 Young GC，單次GC時長較短時間可控并且頻率均勻，所以商品服務(wù)還能正常運(yùn)行。
解決這個問題，可以從三方面入手：減少對象的創(chuàng)建，增大新生代以及調(diào)整幸存區(qū)。
減少對象創(chuàng)建，本質(zhì)上不算是JVM調(diào)優(yōu)，而是代碼優(yōu)化，而且需要花大量的時間去擼代碼，再逐步優(yōu)化代碼，周期會相當(dāng)長。所以就暫時作罷了！
調(diào)整新生代比例
增大新生代比例。只需要修改JVM參數(shù)即可，說起來簡單，但需要多次調(diào)整并壓測，最終找到一個平衡點，在保證FullGC的頻次和耗時都在合理的范圍之內(nèi)，把Young GC的頻次降到最低。
有人可能會問：增大新生代比例，會不會導(dǎo)致Young GC的耗時明顯增大？雖然降低了GC頻次，但是單次GC的耗時卻明顯增加了，豈不是得不償失？
首先，我們需要先明確，目前主流的新生代收集器大多采用標(biāo)記-復(fù)制算法，ParNew也一樣。研究表明，絕大多數(shù)應(yīng)用場景，新生代中98%的對象生命周期很短，在毫秒級別，基本上被使用一次后就會變成垃圾對象，會在下一次GC時被清理掉。在很多JVM中將堆內(nèi)存分為一塊較大的Eden空間和兩塊較小的Survivor空間(下圖的S0和S1)，新生對象存放在Eden區(qū)。當(dāng)發(fā)生Young GC時，將Eden和當(dāng)前Survivor中存活的對象一次性復(fù)制到另外一塊Survivor中，最后整體清理Eden和當(dāng)前的Survivor空間。每次Young GC時兩塊Survivor區(qū)互相更換。HotSpot虛擬機(jī)默認(rèn)Eden和兩塊Survivor的大小比例是8:1:1，也就是說每次新生代中可用內(nèi)存為整個新生代容量的90%（80%+10%），只有10%的內(nèi)存會被“浪費(fèi)”。
現(xiàn)在我們清楚了ParNew回收器采用了標(biāo)記-復(fù)制算法。現(xiàn)在來分析一下ParNew回收器GC耗時和新生代大小的關(guān)系。我們知道標(biāo)記-復(fù)制算法分為兩個階段，標(biāo)記階段和復(fù)制階段。為了簡化問題我們暫且認(rèn)為標(biāo)記階段只掃描新生代的存活對象，其實該階段還需要掃描部分老年代對象。假設(shè)我們要把新生代擴(kuò)容1.5倍。
擴(kuò)容前：新生代容量為2G，假設(shè)某對象A的存活時間為600ms，Young GC間隔500ms，那么本次GC時間 = 掃描新生代時間 + 復(fù)制對象時間（Eden和當(dāng)前Survivor復(fù)制到另一個Survivor）。
擴(kuò)容后：新生代容量為3G ，對象A的生命周期為600ms，但是由于新生代擴(kuò)容了1.5倍，所以Young GC間隔理論上增加到了750ms。此時發(fā)生Young GC，對象A已經(jīng)用完了生命周期，成為了垃圾對象，就不需要把對象A復(fù)制到另一個Survivor區(qū)了。那么本次GC時間 = 1.5 × 掃描新生代時間，沒有增加復(fù)制時間。
所以，當(dāng)擴(kuò)大新生代容量時，實際上每次GC需要復(fù)制的存活對象并不會按照擴(kuò)容比例遞增。容量擴(kuò)大到1.5倍，增加的存活對象會遠(yuǎn)小于1.5倍。雖然標(biāo)記階段消耗的時間提高到了1.5倍，但是復(fù)制階段耗時并沒有明顯提高。更重要的是，對于虛擬機(jī)來說，復(fù)制對象的成本要遠(yuǎn)高于掃描標(biāo)記的成本，所以，單次Young GC時間更多取決于存活對象的數(shù)量，而非Eden區(qū)的大小。如果堆內(nèi)存中存在大量短生命周期的對象（大部分場景是這樣的），那么擴(kuò)容新生代后，Young GC時間不會顯著增加。
分代調(diào)整
此外，觀察了各代齡的對象數(shù)量情況后，對代齡設(shè)置也做了調(diào)整。
前文提到，當(dāng)發(fā)生Young GC時，會將Eden和當(dāng)前的Survivor中存活的對象一次性復(fù)制到另外一塊Survivor中，最后整體清理Eden和當(dāng)前的Survivor空間。每次Young GC時兩塊Survivor區(qū)會互相更換。存活對象在兩塊Survivor區(qū)之間每交換一次，對象年齡就會增長一歲。直到達(dá)到MaxTenuringThreshold設(shè)置的年齡（默認(rèn)是15歲）時，相應(yīng)的對象就會被轉(zhuǎn)移到老年代。所以為了減少復(fù)制成本，MaxTenuringThreshold要盡量合理，不能設(shè)置太大，否則有些長壽對象在每次GC時都會在兩個Survivor區(qū)之間來回復(fù)制，無疑是增加了復(fù)制階段的耗時。
看上圖，在15個分代中，7歲以上的對象80%都會被轉(zhuǎn)移到老年代（769.02除以980.48 ≈ 80% ）。于是我們把 MaxTenuringThreshold 的值調(diào)整為 7，將年齡超過7歲的對象直接轉(zhuǎn)移到老年代。這樣就減少了長壽對象在兩個 survivor 區(qū)之間來回復(fù)制帶來的性能開銷。
偏向鎖停頓
我們看到GC log里有很多18ms左右的停頓，雖然每次停頓時間不算長，但頻繁的停頓對性能消耗還是比較明顯。
這個問題曾經(jīng)遇到過幾次，基本都是偏向鎖導(dǎo)致。JDK1.8 之后 JVM 對鎖進(jìn)行了優(yōu)化，增加了偏向鎖。所謂的偏向，就是偏心，偏向鎖會偏向于當(dāng)前已經(jīng)占有鎖的線程 。適合鎖競爭不激烈的場景（某個同步塊并發(fā)不高，很少會出現(xiàn)多線程同時競爭鎖的場景）。大概過程如下，獲得鎖的線程再次獲得鎖時，會判斷偏向鎖是否指向自己，如果指向自己，該線程將不用再次獲得鎖，就可以直接進(jìn)入同步塊，以此來優(yōu)化性能。當(dāng)其他線程請求相同的鎖時，偏向模式結(jié)束。偏向鎖的實現(xiàn)就是將對象頭的標(biāo)記設(shè)置為偏向，并將線程ID寫入對象頭。
在競爭激烈的場景，偏向鎖會增加系統(tǒng)負(fù)擔(dān)， 因為每次都要加一次是否偏向的判斷。關(guān)鍵是遇到鎖競爭時，取消鎖的過程需要等待全局安全點（safe point），會導(dǎo)致所有線程暫停，即會發(fā)生Stop-The-World。所以在鎖競爭激烈的場景下，最好提前關(guān)閉掉偏向鎖。
在JVM中默認(rèn)會開啟偏向鎖，所以我們只需要關(guān)閉偏向鎖即可：
-XX:-UseBiasedLocking
最后
經(jīng)過一輪調(diào)整和壓測，最終新生代調(diào)整到了2.9G，整個堆內(nèi)存保持8G不變，MaxTenuringThreshold調(diào)成了7。新生代增大了將近1.5倍，Young GC 的頻率減少了大概1/3。GC 的吞量提高了3.8%，達(dá)到了96.8%，。Young GC 平均耗時稍有上升，從60ms上升到了71ms，基本符合預(yù)期。另外Full GC 的頻率和耗時也在可接受的范圍。
調(diào)優(yōu)是個復(fù)雜、細(xì)致的活兒，要因地制宜。不同的機(jī)器、不同的應(yīng)用、不同的業(yè)務(wù)場景和不同的訪問量級，調(diào)優(yōu)的方式都不同，沒有一個固定的模式。做JVM調(diào)優(yōu)之前，建議先了解JVM運(yùn)行原理，內(nèi)存模型，GC過程，相關(guān)GC回收器回收機(jī)制，回收算法。先把基礎(chǔ)知識打扎實，再加上耐心和決心才能夠真正做好JVM優(yōu)化，成為JVM高手。
