第記一次線程爆滿導致服務器崩潰的問題排查及解決目錄問題介紹1.重啟服務器2.修改最大線程數3.查找線程最大的java程序4.導出問題程序的線程日志5.找到問題代碼6.解決方案

問題介紹

測試服務器突然無法連接，ssh登錄不上。只有重啟才能解決。重啟一天后，又連接不上了。

于是有了下面的排查過程，最終發現是有個java程序一直在創建線程，導致線程達到服務器最大數量，服務器崩潰。

1.重啟服務器

重啟后，ssh連接發現下面問題

forkfaild:Cannotallocatememory

以為是內存滿了

于是，free-h,查看內存情況，還有，觀察一段時間后，內存沒多大變化

2.修改最大線程數

經過各種百度，都說可以通過修改服務器的最大線程數來解決，于是我也這么干了。當時做的時候沒有截圖，所以下面截圖是網上找的，湊合看看。

查看最大進程數sysctlkernel.pid_max

ps-eLf|wc-l查看進程數

修改最大進程數后系統恢復

echo1000000/proc/sys/kernel/pid_max

永久生效

echo"kernel.pid_max=1000000"/etc/sysctl.conf

sysctl-p

3.查找線程最大的java程序

上一步擴大了線程數量后，感覺有點不對，因為之前沒有這么配置都可以正常運行，為什么突然服務器掛了呢？肯定是有程序在作怪。

于是決定找出占用線程最多的程序。回顧最近幾天，服務器中只部署了幾個springboot程序。問題一定出在它們之中。

查看線程數量前20的java程序

ps-Lef|awk‘{sum[$2]++}END{for(pidinsum)printpid,sum[pid]}'|sort-nr-k2|head-n20

[root@se-test-lky01~]#ps-Lef|awk'{sum[$2]++}END{for(pidinsum)printpid,sum[pid]}'|sort-nr-k2|head-n20

160743100

313861226

201201072

19548985

9697829

3005796

641344

19016324

16924315

17870300

6417293

8351171

7332168

18259167

19821161

16311157

18433151

18048136

14347104

2559100

觀察一段時間后，發現進程id為16074的java程序的線程數不斷增長。

4.導出問題程序的線程日志

[root@se-test-lky01~]#jstack16074thread_dump.log

分析日志，發現下面情況，線程數量不斷增加，代碼位置在FtpMonitorProcess.java:85

"Thread-4655"#4774prio=5os_prio=0tid=0x00007f84aa2fe000nid=0xd408bwaitingformonitorentry[0x00007f802b704000]

java.lang.Thread.State:BLOCKED(onobjectmonitor)

atcn.cloudwalk.bat.util.http.FtpUtil.connect(FtpUtil.java:246)

-waitingtolock0x00000006c09c1888(ajava.lang.Classforcn.cloudwalk.bat.util.http.FtpUtil)

atcess.FtpMonitorProcess$1.run(FtpMonitorProcess.java:85)

atjava.lang.Thread.run(Thread.java:748)

"Thread-4654"#4773prio=5os_prio=0tid=0x00007f84aa2fc000nid=0xd408awaitingformonitorentry[0x00007f802b805000]

java.lang.Thread.State:BLOCKED(onobjectmonitor)

atcn.cloudwalk.bat.util.http.FtpUtil.connect(FtpUtil.java:246)

-waitingtolock0x00000006c09c1888(ajava.lang.Classforcn.cloudwalk.bat.util.http.FtpUtil)

atcess.FtpMonitorProcess$2.run(FtpMonitorProcess.java:114)

atjava.lang.Thread.run(Thread.java:748)

5.找到問題代碼

發現這個方法每次被調用就會創建一個新的線程。而這個方法是被定時任務調用的，每10秒調用一次。

問題就出在ftp沒有配置，所以線程內執行ftp操作時，線程阻塞，沒能釋放。若ftp可用，則不會出現線程阻塞問題。

這就是問題根源。

privatevoidlistDeviceFiles(){

newThread(newRunnable(){

@Override

publicvoidrun(){

logger.debug("開始獲取[ftp-設備]文件...");

try{

StringworkDir=ftpConfig.getWorkdir();

//連接

FTPClientftpClient=FtpUtil.connect(ftpConfig);

ftpClient.changeWorkingDirectory(workDir);

ftpClient.changeWorkingDirectory(SubscribeDataTypeEnum.DEVICE_INFO.getKey().toString());

FTPFile[]files=ftpClient.listFiles();

for(FTPFilefile:files){

decomposeFile(file,ftpClient);

ftpClient.logout();

}catch