您好，這里是「碼農鏢局」CSDN博客，歡迎您來，歡迎您再來～
在互聯(lián)網(wǎng)大廠中，對每天億級流量的日志進行清洗、整理是非常常見的工作。在某個系統(tǒng)中，需要對用戶的訪問日志做脫敏處理，也就是清洗掉姓名、身份證號、手機號等個人隱私信息后在保存到數(shù)據(jù)庫中或者交付給其他應用使用。
系統(tǒng)的設計者是直接從kafka中獲得的日志數(shù)據(jù)，再交由清洗系統(tǒng)進行處理。結構圖是在這樣的：
一段時間后，發(fā)現(xiàn)系統(tǒng)運行越來越慢，還出現(xiàn)了卡頓現(xiàn)象。經(jīng)過調取GC日志文件后發(fā)現(xiàn)，業(yè)務代碼中出現(xiàn)了大量的遞歸操作。于是又通過MAT工具分析OOM快照，定位遞歸代碼產(chǎn)生的地方。最終，得出的結論是：遞歸調用次數(shù)并不是很多，幾十次而已，完全在合理范圍內。但遞歸所創(chuàng)建的總的char[]數(shù)組大小1G左右。由此可知，并不一定全是代碼問題。繼續(xù)順著問題往下查，通過排查JVM參數(shù)的設置，發(fā)現(xiàn)JVM的堆內存設置過小，僅有1G，而且年輕代內存也過小。這才導致系統(tǒng)頻繁卡頓，原來是在不停地執(zhí)行GC。
所以，解決方案就非常明確了。
該系統(tǒng)部署在Tomcat中。解決了年輕代的問題沒過多久，又出現(xiàn)了經(jīng)常假死，但過一會又能正常訪問。這就有點讓人費解了。起初以為是硬件資源不足，所以使用top命令檢查機器資源使用情況。針對機器配置（4C8G）和資源狀況（1%CPU和50%+RAM）對系統(tǒng)問題進行初步排查定位。然后用通過jstat分析，沒有發(fā)現(xiàn)新的OOM和異常的GC。通過導出內存快照，使用MAT進行分析，最終發(fā)現(xiàn)有太多的ClassLoader，而且每個ClassLoader都加載了大量的byte[]數(shù)組。原來，為了在系統(tǒng)啟動時就做一些業(yè)務上的干預，開發(fā)工程師對ClassLoader做了一些自定義的修改而沒有顧忌對性能的消耗。因此，解決方案也非常簡單：
1、修改自定義ClassLoader的加載方式；
2、限制ClassLoader的創(chuàng)建數(shù)量。
再來稍微回顧一下：
GC問題定位一般會采?。?/p>
1、分析GC日志；
2、使用jstat工具；
3、使用jmap工具。
而OOM問題的分析解決，則一般會采取：
1、線上系統(tǒng)監(jiān)控；
2、用MAT工具。
這兩種方法來解決。文章來源：http://www.zghlxwxcb.cn/news/detail-609889.html
感謝您的大駕光臨！歡迎騷擾，不勝榮幸～文章來源地址http://www.zghlxwxcb.cn/news/detail-609889.html
到了這里，關于JVM系統(tǒng)優(yōu)化實踐（23）：GC生產(chǎn)環(huán)境案例（6）的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
