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