close wait 致使的java web容器假死

1.現象

線上tomcat或後臺task java進程偶發性出現假死，徹底沒有規律

1.1 java環境

java -version

1.2 linux環境

// 查看操做系統版本信息
cat /proc/version

// 查看操做系統內核信息
uname -a

// 查看系統版本信息的命令
 lsb_release -a

2.分析步驟

2.1 查看進程存活狀態

ps -ef | grep java

查詢到該進程的ID是12635，監聽的端口是10061，後面會用到

2.2 查看該端口的監聽狀況

// 查看該tomcat服務監聽的端口，並將結果輸出至日誌文件
netstat -an | grep 10061 >> netstat-sku.log

// 查看前200行內容
head -n 200 netstat-sku.log

發現大量close wait，初步能夠判斷是close wait致使的假死

2.3 查看內存使用狀況

// 查看內存使用狀況
jmap -heap 12635

Eden Space 內存基本耗費完，但沒有觸發GC

2.4 查看線程狀態

-F to force a thread dump. Use when jstack <pid> does not respond (process is hung) 強制線程轉儲。當jstack <pid>沒有響應時使用(進程掛起)

// 將該進程的全部線程信息打印輸出至指定文件
jstack -F 12635 >> jstack-12635.log

發現全部的線程處於BLOCKED狀態

2.5 jstack -F後發現該tomcat進程從假死狀態恢復到正常狀態

3.結論(未完待續)

3.1 初步判斷

極其像Linux內核的一個bug, 某個switch分支缺乏memory barrier的正確處理，致使外部應用如JVM的lock被錯誤鎖住；通常jstack連後就恢復 連接地址

參考資料

• https://www.infoq.com/news/2015/05/redhat-futex
• https://stackoverflow.com/questions/35165455/suspended-jvm-jstack-f-pid-only-fix

掃描二維碼關注「熊英的小屋」，這裏永遠有一個位置爲你開放