1、問題描述

springboot搭建的項(xiàng)目打包成jar包部署到Linux操作系統(tǒng)中，采用nohup java -jar 部署 jar 包后過一段時(shí)間(兩三天)后莫名其妙掛掉(進(jìn)程號(hào)PID被殺)。

2、問題定位

2.1 度娘一下

遇到這種問題，首先當(dāng)然是去度娘找找看看有沒有相似的人有這樣的bug，看看別人的處理方法解決，結(jié)果當(dāng)然是沒找到合適的博客，所以就只能自己摸索摸索解決之道了。

2.2 基本操作

既然沒有找到想要的，這種情況百分之九十九點(diǎn)九九九......的概率是內(nèi)存泄露導(dǎo)致的。

那基本操作來一下

2.2.1 top、free -m 指令

先用top指令看下Linux系統(tǒng)中的進(jìn)程號(hào)使用情況

從上圖可看到，cpu的占用竟然干到了 100.3%以上，這么耗費(fèi)cup資源，肯定就是程序有問題了。

接著用 free -m查看下內(nèi)存使用情況

結(jié)果發(fā)現(xiàn)這個(gè)空閑內(nèi)存越來越少了，還真的是內(nèi)存有問題。

3、問題深入定位

上面只是初步知道程序有問題，但是還是不知道具體的問題再哪里？

就是這個(gè)問題在代碼中哪里造成的還是不清楚

3.1 top -Hp PID 指令

輸入PID指令將程序進(jìn)程號(hào)的子線程使用系統(tǒng)資源的線程列舉出來

從上圖中可以看到733這個(gè)子線程占用了99.9%的cup使用率，這個(gè)線程肯定是有問題的，這個(gè)就要進(jìn)入到JVM的棧中分析問題了，這里需要使用jstack工具進(jìn)行分析問題。

3.2  jstack -l PID |grep -A 10 NID

因?yàn)樵跅Ｖ械木€程號(hào)是以16進(jìn)制進(jìn)行的，所以需要將上面733這個(gè)線程號(hào)轉(zhuǎn)成16進(jìn)制的數(shù)據(jù)，直接在Linux中轉(zhuǎn)換： printf "%x\n"  733

然后采用jstack棧分析工具進(jìn)行問題分析

jstack -l 655 |grep -A 10 0x2dd

這里的10是指打印10行的日志

找到這個(gè)子線程號(hào)，并且看到自己的報(bào)名和類，這個(gè)線程占用cpu 99.9%以上的資源就在類

ServerHandler的129行，趕緊去看看自己這個(gè)類的第129行到底寫了什么東西。

這段代碼直接導(dǎo)致了死循環(huán)，該段代碼是希望讀到輸入流里面總的字節(jié)大小，但有時(shí)候因?yàn)榫W(wǎng)絡(luò)原因無法一次讀到結(jié)果，再加上while死循環(huán)，如果一直讀不到，死循環(huán)就一直執(zhí)行下去，故造成了死循環(huán)

4、解決

將上面導(dǎo)致死循環(huán)的代碼注釋掉改為緩存處理

5、后續(xù)

以上是一次線程問題的解決，其實(shí)一次線上問題解決沒有那么快就排查出來的，如果涉及到堆問題，需要將堆問題、棧日志打印保存下來分析

堆文件生成：

jmap -dump:format=b,file=heap.hprof pid //保存了堆現(xiàn)場(chǎng),b這里是字節(jié)的意思

（生成的堆文件采用mat分析軟件定位問題）

• 棧日志生成：jstack pid > jstack.log //線程棧的現(xiàn)場(chǎng)
• gc執(zhí)行情況：jstat -gcutil 6343 5000  //每隔5秒檢查gc使用情況

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論