摘要:直接顯示了一個疑似內存泄漏的問題。然后分析文件給出的信息,發現一個叫的類。文件里面說的內存泄漏的大概的意思就是說,這個類里面的存放的東西太多了,爆掉了。修改了代碼將調用的地方改成了單例。修改完線上跑了一段日子,后來也沒有出現過這樣的問題。
問題描述:
????早上去公司上班,突然就郵件一直報警,接口報異常,然后去查服務器的運行情況,發現java的cpu爆了.接著就開始排查問題
問題解決過程:1.先服務器(centos7)上,使用了top和uptime命令,發現時java的cpu爆了,超過100%了,導致后續的服務無法正常提供;
2.調整了負載均衡,下掉了有問題的那幾臺機器;
3.使用jps找到了運行著的tomcat的pid,這里假設為10086;
4.使用jstat -gcutil 10086 500 10 (意思是對pid為10086的線程,每500ms顯示各分代的內存使用情況), 這里給一下部分jvm的參數設置,如下:
可以看到對新生代使用的是ParNew收集器,對老年代使用的是CMS收集器,CMSInitiatingOccupancyFraction=80說明當使用率超過80%的時候觸發垃圾回收。然后發現,線上老年代一直超過80%的使用率,幾乎一秒不到就進行了一次FGC,這么頻繁的FGC導致了服務無法正常運行;
5.使用jmap -histo 查看了是哪些對象的數量最多,如果參數是-histo:live的話,會在進行一次FGC后,顯示當前的使用數量最多的實例。查看后發現有大量的ConcurrentHashMap的Node節點實例,于是去代碼中搜索使用到ConcurrentHashMap的地方,有好幾處使用比較頻繁的地方,看了代碼后分析,可能是圖片上傳,下載的問題,但也不能斷定。
6.使用jmap -dump:format=b,file=/usr/local/tomcat/dump1將內存的情況給拉下來.如下:
文件生成后,將dump1放入到eclipse的mat中進行分析。直接顯示了一個疑似內存泄漏的問題。然后分析dump文件給出的信息,發現一個叫IdleConnectionReaper的類。dump文件里面說的內存泄漏的大概的意思就是說,IdleConnectionReaper這個類里面的ArrayList存放的東西太多了,爆掉了。如下:
從oss的jar包里面找到這個類以后,簡單的看一下這個類的構成,如下:
通過查找一些官方的資料和源代碼的閱讀,發現這個是一個oss的守護線程,用來檢測上傳或者下載的工作線程,每60秒就會去檢查一下空閑的工作線程,并且將它們回收。然后它內部有一個靜態的ArrayList,里面保存的是ossClient的鏈接,默認是1024個。
7.所以大概原因找到了,就是ossClient的鏈接太多了,扛不住了,所以一直在進行FGC,導致服務不可用了,最后找到相關的代碼,發現有個小方法里面在每次上傳或者下載的時候,都會去創建一個ossClient。修改了代碼將ossClient調用的地方改成了單例。修改完線上跑了一段日子,后來也沒有出現過這樣的問題。
1.大量的請求,調用的地方要注意是否會導致內存的大量消耗,盡可能使用池化技術,單例等,減少創建,銷毀的系統開銷;
2.CMS 的幾個缺點,可以參考《深入java虛擬機》,對CPU占用會比較高,無法處理浮動垃圾,還有就是CMS使用的是標記-清除算法,會導致大量的空間碎片,碎片過多的話,導致分配大對象很困難,所以不得不進行FGC,也可能是這個原因導致了本文說的一直FGC的問題。解決方式:
-XX:+UseCMSCompactAtFullCollection:使用并發收集器時,開啟對年老代的壓縮(會整理內存碎片,默認是開啟的);
-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設置多少次Full GC后,對年老代進行壓縮,會使得FGC的時間變長,但是可以提升內存空間的使用率,讓大對象可以更容易分配,而不需要多次FGC。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/73635.html
摘要:問題線上定時任務計算出的金額不對定位問題查看日志好像也執行了但是金額為什么和數據庫的表里的不一致再查整個的定時任務日志日切日期 問題: 線上riskProvision定時任務,計算出的金額不對 定位問題: 查看日志 4.13 riskProvision 2017-04-13 01:10:00.009 [org.springframework.scheduling.quartz....
摘要:并且在對的抽象中,每一行,每一個單元格都是一個對象。對支持使用官方例子需要繼承,覆蓋方法,每讀取到一個單元格的數據則會回調次方法。概要Java對Excel的操作一般都是用POI,但是數據量大的話可能會導致頻繁的FGC或OOM,這篇文章跟大家說下如果避免踩POI的坑,以及分別對于xls和xlsx文件怎么優化大批量數據的導入和導出。一次線上問題這是一次線上的問題,因為一個大數據量的Excel導出...
摘要:直到有一天你會碰到線上奇奇怪怪的問題,如線程執行一個任務遲遲沒有返回,應用假死。正好這次借助之前的一次生產問題來聊聊如何排查和解決問題。本地模擬上文介紹的是線程相關問題,現在來分析下內存的問題。盡可能的減少多線程競爭鎖。 showImg(https://segmentfault.com/img/remote/1460000015568421?w=2048&h=1150); 前言 之前或...
閱讀 3408·2021-09-22 16:00
閱讀 3452·2021-09-07 10:26
閱讀 2989·2019-08-30 15:55
閱讀 2858·2019-08-30 13:48
閱讀 1366·2019-08-30 12:58
閱讀 2162·2019-08-30 11:15
閱讀 945·2019-08-30 11:08
閱讀 525·2019-08-29 18:41