1、問題描述

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

2、問題定位

2.1 度娘一下

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

2.2 基本操作

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

那基本操作來一下

2.2.1 top、free -m 指令

先用top指令看下Linux系統(tǒng)中的進程號使用情況

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

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

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

3、問題深入定位

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

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

3.1 top -Hp PID 指令

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

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

3.2  jstack -l PID |grep -A 10 NID

因為在棧中的線程號是以16進制進行的，所以需要將上面733這個線程號轉(zhuǎn)成16進制的數(shù)據(jù)，直接在Linux中轉(zhuǎn)換： printf "%x\n"  733

然后采用jstack棧分析工具進行問題分析

jstack -l 655 |grep -A 10 0x2dd

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

找到這個子線程號，并且看到自己的報名和類，這個線程占用cpu 99.9%以上的資源就在類

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

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

4、解決

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

5、后續(xù)

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

堆文件生成：

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

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

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

總結(jié)

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

最新評論