在高并發下，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/
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/298546.html
標籤：Java
下一篇：資料庫基礎之樹形查詢結構設計