這兩天遇到一個服務假死的問題，具體現(xiàn)象就是服務不再接收任何請求，客戶端會拋出Broken Pipe。

01 檢查系統(tǒng)狀態(tài)

執(zhí)行top，發(fā)現(xiàn)CPU和內存占用都不高，但是通過命令

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

發(fā)現(xiàn)有大量的CLOSEWAIT端口占用，繼續(xù)調用該服務的api，等待超時之后發(fā)現(xiàn)CLOSEWAIT的數量也沒有上升，也就是說服務幾乎完全僵死。

02 檢查JVM情況

懷疑可能是線程有死鎖，決定先dump一下線程情況，執(zhí)行

jstack > /tmp/thread.hump

發(fā)現(xiàn)tomcat線程基本也正常，都是parking狀態(tài)。

這就比較奇怪了，繼續(xù)想是不是GC導致了STW，使用jstat查看垃圾回收情況

app@server:/tmp$ jstat -gcutil 1 2000 10 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 27.79 65.01 15.30 94.75 92.23 1338 44.375 1881 475.064 519.439

一看嚇一跳，FGC的次數居然超過了YGC，時長有475s。一定是有什么原因觸發(fā)了FGC，好在我們打開了GC log。

發(fā)現(xiàn)一段時間內頻繁發(fā)生Allocation Failure引起的Full GC。而且eden區(qū)的使用占比也很大，考慮有頻繁新建對象逃逸到老年代造成問題。詢問了一下業(yè)務的開發(fā)，確認有一個外部對接API沒有分頁，查詢后可能會產生大量對象。

由于外部API暫時無法聯(lián)系對方修改，所以為了先解決問題，對原有的MaxNewSize進擴容，從192MB擴容到一倍。經過幾天的觀察，發(fā)現(xiàn)gc基本趨于正常

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 3.37 60.55 8.60 95.08 92.98 87 2.421 0 0.000 2.421

擴容之前對heap進行了dump

jmap -dump:format=b,file=heapDump

通過MAT分析內存泄露，居然疑似是jdbc中的一個類，但其實整體占用堆容量并不多。

分析了線程數量，大約是240多條，與正常時也并沒有很大的出入。而且大量的是在sleep的定時線程。

03 總結

本次排查其實并未找到真正的原因，間接表象是FGC頻繁導致服務假死。而且acturator端口是正常工作的，導致health check進程誤認為服務正常，沒有觸發(fā)告警。如果你也遇到類似的情況歡迎一起討論。

總結

以上是生活随笔為你收集整理的linux进程假死的原因_一次Spring Boot假死诊断的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。