前言：

事情是醬紫的，系統(tǒng)上線兩個(gè)月后，風(fēng)平浪靜。在一個(gè)秋天寧?kù)o的下午，老衲正喝著茶聽(tīng)著歌敲著代碼，順便欣賞下妹紙，獨(dú)享這難得的愜意。突然手機(jī)響了，一看來(lái)電，心中一沉，項(xiàng)目經(jīng)理來(lái)電，必有蹊蹺。匆忙接起電話，沒(méi)有問(wèn)候，直奔主題，“趕緊看下系統(tǒng)，個(gè)別客戶反饋系統(tǒng)不能用了，先恢復(fù)系統(tǒng)，再排查問(wèn)題”。

老衲撂下電話，一哆嗦，趕緊連上VPN，直奔服務(wù)器主機(jī)。

PS：三臺(tái)服務(wù)器（centos、128G內(nèi)存、32核CPU），tomcat1.7，jdk1.8，通過(guò)F5負(fù)載

解決步驟：

1、top命令查看CPU占用情況

可以看到11042進(jìn)程占用了非常多的CPU資源

2、查看F5并發(fā)曲線：為什么應(yīng)用耗費(fèi)了這么多的線程，難道是用戶量突然上來(lái)了，調(diào)取了F5的訪問(wèn)曲線圖，可以看到在15:57左右并發(fā)量突然猛漲，當(dāng)時(shí)根據(jù)曲線懷疑是請(qǐng)求量徒增導(dǎo)致

3、查看系統(tǒng)請(qǐng)求量：根據(jù)應(yīng)用系統(tǒng)日志、以及l(fā)ocalhost_access_log日志 查看此節(jié)點(diǎn)用戶訪問(wèn)日志，發(fā)現(xiàn)使用人數(shù)并未徒增，根據(jù)請(qǐng)求量繪制的曲線如下：

可以看到曲線并未出現(xiàn)請(qǐng)求量徒增。

4、查看進(jìn)程內(nèi)線程運(yùn)行情況：沒(méi)有大量請(qǐng)求，為什么CPU會(huì)被使用這么多，難道是有線程的死鎖，

執(zhí)行top -p 11042 -H 查看進(jìn)程內(nèi)所有線程的運(yùn)行情況：

可以看到有很多線程正在執(zhí)行

5、接著打內(nèi)存快照?qǐng)?zhí)行命令打內(nèi)存快照 在 jdk1.8.0_131/bin下面執(zhí)行 ./jstack -l 11042>log01.txt，然后又隔了一分鐘再次執(zhí)行./jstack -l 11042>log02.txt，生產(chǎn)兩個(gè)文件好對(duì)比里面的線程交集

打開(kāi)日志，并未發(fā)現(xiàn)死鎖的線程，但是在兩個(gè)文件里面卻發(fā)現(xiàn)大量的GC線程在執(zhí)行如圖：

6、分析GC回收情況，在jdk bin目錄下執(zhí)行 ./jstat -gcutil 11042 1000 100

看到了沒(méi)有，虛擬機(jī)正在瘋狂的進(jìn)行full GC 回收，垃圾回收線程占用了非常多的CPU資源，問(wèn)題已經(jīng)有了明確的方向了，接下來(lái)需要分析到底是什么導(dǎo)致了full GC的頻繁觸發(fā)。

7、分析堆內(nèi)存：

打印堆內(nèi)存 在jdk bin目錄下執(zhí)行 ./jmap -dump:live,format=b,file=problem.bin 11042 ，將日志文件下載到本地使用jprofiler分析，

發(fā)現(xiàn)有大量char[]，String ,map 占用，那么是什么業(yè)務(wù)代碼造成了以上大量的數(shù)據(jù)呢，打開(kāi) char[]，String 沒(méi)有找到與之關(guān)聯(lián)的業(yè)務(wù)代碼， 在map中發(fā)現(xiàn)大量的相同的業(yè)務(wù)對(duì)象，但是卻無(wú)法直接發(fā)現(xiàn)出是什么操作造成了大量業(yè)務(wù)對(duì)象的存在，因?yàn)榇藰I(yè)務(wù)對(duì)象代碼中大量使用一一排除的話工作量極大。

一時(shí)陷入困境，靈機(jī)一動(dòng)，是不是還有別的內(nèi)存快照分析工具，一查有個(gè)mat，在eclipse裝好插件，打開(kāi)內(nèi)存快照：

點(diǎn)擊leak suspects，如圖

在個(gè)給出問(wèn)題中一一查看，這時(shí)問(wèn)題出現(xiàn)了如圖：

BaseDatagridRest 的export導(dǎo)出數(shù)據(jù)方法，突然想到系統(tǒng)中有某個(gè)表數(shù)據(jù)的導(dǎo)出，立即登錄系統(tǒng)查看此項(xiàng)導(dǎo)出功能，發(fā)現(xiàn)這個(gè)導(dǎo)出未對(duì)數(shù)據(jù)量做限制，而且BaseDatagridRest 的export方法實(shí)現(xiàn)是將數(shù)據(jù)庫(kù)中的表數(shù)據(jù)抽取到內(nèi)存中然后回寫到excle中，讓用戶下載。

我登錄測(cè)試環(huán)境，用大數(shù)據(jù)量測(cè)試了下導(dǎo)出果然出現(xiàn)了同樣的問(wèn)題，至此問(wèn)題水落石出，解決方案很簡(jiǎn)單，導(dǎo)出數(shù)據(jù)量加上限制，為了防止因?yàn)閷?dǎo)出過(guò)慢時(shí)用戶多次點(diǎn)擊加上和遮罩。

總結(jié)：GC不只是用來(lái)面試的，更是來(lái)解決問(wèn)題的。

以上這篇解決java web應(yīng)用線上系統(tǒng)偶發(fā)宕機(jī)的情況就是小編分享給大家的全部?jī)?nèi)容了，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論