記錄一次Spring Boot假死診斷

轉載自本人博客
原文地址： https://www.deanwangpro.com/2...

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

檢查系統狀態

執行top，發現CPU和內存佔用都不高，可是經過命令

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

發現有大量的CLOSE_WAIT端口占用，繼續調用該服務的api，等待超時以後發現CLOSE_WAIT的數量也沒有上升，也就是說服務幾乎徹底僵死。

檢查JVM狀況

懷疑多是線程有死鎖，決定先dump一下線程狀況，執行

jstack <pid> > /tmp/thread.hump

發現tomcat線程基本也正常，都是parking狀態。

這就比較奇怪了，繼續想是否是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。必定是有什麼緣由觸發了FGC，好在咱們打開了GC log。

發現一段時間內頻繁發生Allocation Failure引發的Full GC。並且eden區的使用佔比也很大，考慮有頻繁新建對象逃逸到老年代形成問題。詢問了一下業務的開發，確認有一個外部對接API沒有分頁，查詢後可能會產生大量對象。

因爲外部API暫時沒法聯繫對方修改，因此爲了先解決問題，對原有的MaxNewSize進擴容，從192MB擴容到一倍。通過幾天的觀察，發現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 <PID>

經過MAT分析內存泄露，竟然疑似是jdbc中的一個類，但其實總體佔用堆容量並很少。

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

總結

本次排查其實並未找到真正的緣由，間接表象是FGC頻繁致使服務假死。並且acturator端口是正常工做的，致使health check進程誤認爲服務正常，沒有觸發告警。若是你也遇到相似的狀況歡迎一塊兒討論。