來源：https://heapdump.cn/article/1859160 通過這一個多月的努力，將 FullGC 從 40 次/天優化到近 10 天才觸發一次，而且 YoungGC 的時間也減少了一半以上，這麼大的優化，有必要記錄一下中間的調優過程。 對於 JVM 垃圾回收，之前一直都是處於理論 ...
來源：https://heapdump.cn/article/1859160
通過這一個多月的努力，將 FullGC 從 40 次/天優化到近 10 天才觸發一次，而且 YoungGC 的時間也減少了一半以上，這麼大的優化，有必要記錄一下中間的調優過程。
對於 JVM 垃圾回收，之前一直都是處於理論階段，就知道新生代，老年代的晉升關係，這些知識僅夠應付面試使用的。
推薦一個開源免費的 Spring Boot 實戰項目：
問題
前一段時間，線上伺服器的 FullGC 非常頻繁，平均一天 40 多次，而且隔幾天就有伺服器自動重啟了，這表明伺服器的狀態已經非常不正常了，得到這麼好的機會，當然要主動請求進行調優了。
未調優前的伺服器 GC 數據，FullGC 非常頻繁。
首先伺服器的配置非常一般（2 核 4G），總共 4 台伺服器集群。每台伺服器的 FullGC 次數和時間基本差不多。其中 JVM 幾個核心的啟動參數為：
-Xms1000M -Xmx1800M -Xmn350M -Xss300K -XX:+DisableExplicitGC -XX:SurvivorRatio=4 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
- -Xmx1800M：設置 JVM 最大可用記憶體為 1800M。
- -Xms1000m：設置 JVM 初始化記憶體為 1000m。此值可以設置與 -Xmx 相同，以避免每次垃圾回收完成後 JVM 重新分配記憶體。
- -Xmn350M：設置年輕代大小為 350M。整個 JVM 記憶體大小 = 年輕代大小 + 年老代大小。增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun 官方推薦配置為整個堆的 3/8。
- -Xss300K：設置每個線程的堆棧大小。JDK5.0 以後每個線程堆棧大小為 1M，以前每個線程堆棧大小為 256K。根據應用的線程所需記憶體大小進行調整。在相同物理記憶體下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在 3000~5000 左右。
第一次優化
一看參數，馬上覺得新生代為什麼這麼小，這麼小的話怎麼提高吞吐量，而且會導致 YoungGC 的頻繁觸發，如上圖的新生代收集就耗時 830s。
初始化堆記憶體沒有和最大堆記憶體一致，查閱了各種資料都是推薦這兩個值設置一樣的，可以防止在每次 GC 後進行記憶體重新分配。
基於前面的知識，於是進行了第一次的線上調優：提升新生代大小，將初始化堆記憶體設置為最大記憶體。
-Xmn350M -> -Xmn800M
-XX:SurvivorRatio=4 -> -XX:SurvivorRatio=8
-Xms1000m ->-Xms1800m
將 SurvivorRatio 修改為 8 的本意是想讓垃圾在新生代時儘可能的多被回收掉。
就這樣將配置部署到線上兩台伺服器（prod，prod2 另外兩台不變方便對比）上後，運行了 5 天後，觀察 GC 結果，YoungGC 減少了一半以上的次數，時間減少了 400s，但是 FullGC 的平均次數增加了 41 次。YoungGC 基本符合預期設想，但是這個 FullGC 就完全不行了。
就這樣第一次優化宣告失敗。
第二次優化
在優化的過程中，我們的主管發現了有個對象 T 在記憶體中有一萬多個實例，而且這些實例占據了將近 20M 的記憶體。於是根據這個 bean 對象的使用，在項目中找到了原因：匿名內部類引用導致的，偽代碼如下：
public void doSmthing(T t){
redis.addListener(new Listener(){
public void onTimeout(){
if(t.success()){
//執行操作
}
}
});
}
由於 listener 在回調後不會進行釋放，而且回調是個超時的操作，當某個事件超過了設定的時間（1 分鐘）後才會進行回調，這樣就導致了 T 這個對象始終無法回收，所以記憶體中會存在這麼多對象實例。
通過上述的例子發現了存在記憶體泄漏後，首先對程式中的 error log 文件進行排查，首先先解決掉所有的 error 事件。然後再次發佈後，GC 操作還是基本不變，雖然解決了一點記憶體泄漏問題，但是可以說明沒有解決根本原因，伺服器還是繼續莫名的重啟。
記憶體泄漏調查
經過了第一次的調優後發現記憶體泄漏的問題，於是大家都開始將進行記憶體泄漏的調查，首先排查代碼，不過這種效率是蠻低的，基本沒發現問題。於是線上上不是很繁忙的時候繼續進行 dump 記憶體，終於抓到了一個大對象。
這個對象竟然有 4W 多個，而且都是清一色的 ByteArrowRow 對象，可以確認這些數據是資料庫查詢或者插入時產生的了。
於是又進行一輪代碼分析，在代碼分析的過程中，通過運維的同事發現了在一天的某個時候入口流量翻了好幾倍，竟然高達 83MB/s ，經過一番確認，目前完全沒有這麼大的業務量，而且也不存在文件上傳的功能。
咨詢了阿裡雲客服也說明完全是正常的流量，可以排除攻擊的可能。
就在我還在調查入口流量的問題時，另外一個同事找到了根本的原因，原來是在某個條件下，會查詢表中所有未處理的指定數據，但是由於查詢的時候 where 條件中少加了模塊這個條件，導致查詢出的數量達 40 多萬條，而且通過 log 查看當時的請求和數據，可以判斷這個邏輯確實是已經執行了的，dump 出的記憶體中只有 4W 多個對象，這個是因為 dump 時候剛好查詢出了這麼多個，剩下的還在傳輸中導致的。而且這也能非常好的解釋了為什麼伺服器會自動重啟的原因。
解決了這個問題後，線上伺服器運行完全正常了，使用未調優前的參數，運行了 3 天左右 FullGC 只有 5 次。
第二次調優
記憶體泄漏的問題已經解決了，剩下的就可以繼續調優了，經過查看 GC log，發現前三次 FullGC 時，老年代占據的記憶體還不足 30%，卻發生了 FullGC。
於是進行各種資料的調查，在 https://blog.csdn.net/zjwstz/article/details/77478054博客中非常清晰明瞭的說明 metaspace 導致 FullGC 的情況，伺服器預設的 metaspace 是 21M，在GC log中看到了最大的時候 metaspace 占據了 200M 左右，於是進行如下調優，以下分別為 prod1 和 prod2 的修改參數，prod3，prod4 保持不變。
-Xmn350M -> -Xmn800M
-Xms1000M ->1800M
-XX:MetaspaceSize=200M
-XX:CMSInitiatingOccupancyFraction=75
和
-Xmn350M -> -Xmn600M
-Xms1000M ->1800M
-XX:MetaspaceSize=200M
-XX:CMSInitiatingOccupancyFraction=75
prod1 和 2 只是新生代大小不一樣而已，其他的都一致。到線上運行了 10 天左右，進行對比：
prod1：
prod2：
prod3：
prod4：
對比來說，1，2 兩台伺服器 FullGC 遠遠低於 3，4 兩台，而且 1，2 兩台伺服器的 YounGC 對比 3，4 也減少了一半左右。
而且第一臺伺服器效率更為明顯，除了 YoungGC 次數減少，而且吞吐量比多運行了一天的 3，4 兩台的都要多（通過線程啟動數量），說明 prod1 的吞吐量提升尤為明顯。
通過 GC 的次數和 GC 的時間，本次優化宣告成功，且 prod1 的配置更優，極大提升了伺服器的吞吐量和降低了 GC 一半以上的時間。
prod1 中的唯一一次 FullGC：
通過 GC log 上也沒看出原因，老年代在 cms remark 的時候只占據了 660M 左右，這個應該還不到觸發 FullGC 的條件，而且通過前幾次的 YoungGC 調查，也排除了晉升了大記憶體對象的可能，通過 metaspace 的大小，也沒有達到 GC 的條件。這個還需要繼續調查，有知道的歡迎指出下，這裡先行謝過了。
總結
通過這一個多月的調優總結出以下幾點：
- FullGC 一天超過一次肯定就不正常了。
- 發現 FullGC 頻繁的時候優先調查記憶體泄漏問題。
- 記憶體泄漏解決後，jvm 可以調優的空間就比較少了，作為學習還可以，否則不要投入太多的時間。
- 如果發現 CPU 持續偏高，排除代碼問題後可以找運維咨詢下阿裡雲客服，這次調查過程中就發現 CPU 100% 是由於伺服器問題導致的，進行伺服器遷移後就正常了。
- 數據查詢的時候也是算作伺服器的入口流量的，如果訪問業務沒有這麼大量，而且沒有攻擊的問題的話可以往資料庫方面調查。
- 有必要時常關註伺服器的 GC，可以及早發現問題。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！
