在高併發下，Java程序的非正常GC帶來的影響往往會被進一步放大。不管是「GC頻率過快」還是「GC耗時太長」，由於GC期間都存在Stop The World問題，因此很容易導致服務超時，引發性能問題。本期小編爲大家篩選了4篇Young GC問題排查文章，幫大家複習YGC的執行原理和問題排查要點。
1.YGC問題排查，又讓我漲姿勢了！
作者：Rockets
https://heapdump.cn/article/1661497
本文作者分享了一個棘手的Young GC耗時過長的線上案例，首先是收到服務超時告警，發現了YoungGC耗時過長的問題，然後就開始排查。發現問題後的處理堪稱教科書般的操作：“按照GC問題的常規排查流程，我們立刻摘掉了一個節點，然後通過以下命令dump了堆內存文件用來保留現場。jmap -dump:format=b,file=heap pid 最後對線上服務做了回滾處理，回滾後服務立馬恢復了正常，接下來就是長達1天的問題排查和修復過程。”
經過確認JVM配置——檢查代碼——對dump的堆內存文件進行分析——分析YGC處理Reference的耗時——再回到長週期對象進行分析，找出了問題所在：每次調用getConfig方法時都會往List中添加元素，並且未做去重處理，然後立即解決了問題。
文末對YGC相關知識點進行了梳理和總結，從新生代的相關知識講起，帶大家複習了YGC的觸發時機和執行過程。
本文是一篇理論與實戰結合的經典好文，作者不僅分享了自己遇到YGC問題的排查思路，還就此知識點幫大家複習了原理。讀者今後遇到類似的問題可以參考快速分析解決。
2.頻繁操作本地緩存導致YGC耗時過長
作者：阿菜
https://heapdump.cn/article/1578279
本文作者在幫羣友排查YGC耗時過長問題，通過分析堆棧和GC log發現，在某次YGC時，Survivor區中年齡超過7的對象佔用了Survivor空間一半以上。而正常情況下，年輕代對象朝生夕死。網絡服務處理請求爲毫秒級，YGC幾秒甚至十幾秒才發生一次,多數年輕對象活不過1代。於是，猜測該羣友使用了本地緩存。進一步溝通後得出結論：原因一：年輕代中有太多存活的對象，增加了標記時間；原因二：YGC又需要花費大量的時間在掃描Card Table上，總結原因是操作本地緩存太頻繁導致了YGC耗時過長。最後向羣友提出了修改意見解決了問題。
在文章結尾作者還總結了該業務場景的幾條修改建議，很有參考價值。
3.我司基礎組件更新本地緩存策略問題導致young gc時間升高
作者：朱紀兵
https://heapdump.cn/article/1910972
本文作者在一次研究服務QPS和young gc的時間的關係時，發現實際情況與理想狀態不同，於是開始追蹤問題。用gdb 去dump了下來survivor區域中的內容，發現了異常點。最後發現是公司配置中心基礎組件更新本地緩存策略的問題。
作者遇到問題不忽視主動排查反覆驗證的精神值得學習。
4.耗時20多秒的young gc，你見過嗎？
作者：Edenbaby
https://heapdump.cn/article/1907474
作者遇到了耗時20多秒的young gc，在排查時發現user(用戶耗時)+sys(系統耗時) <real(真實耗時)，但大多數的young GC中，real time是小於sys+user time的，因爲paralle垃圾回收器是多線程併發的去GC，所以user time是各個線程累積的一個時間，大概率要大於real time。因此猜測是CPU不夠用或磁盤IO壓力大導致的。 排查YGC異常問題，一定要掌握GC執行過程，會看GC log，從日誌中找到突破點。
更多性能文章，請訪問https://heapdump.cn/