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