Spring Boot假死診斷的實(shí)例分析，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。
創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、上街網(wǎng)絡(luò)推廣、小程序設(shè)計(jì)、上街網(wǎng)絡(luò)營銷、上街企業(yè)策劃、上街品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學(xué)生創(chuàng)業(yè)者提供上街建站搭建服務(wù)，24小時(shí)服務(wù)熱線：028-86922220，官方網(wǎng)址：www.cdcxhl.com
這兩天遇到一個(gè)服務(wù)假死的問題，具體現(xiàn)象就是服務(wù)不再接收任何請求，客戶端會拋出Broken Pipe。
執(zhí)行top，發(fā)現(xiàn)CPU和內(nèi)存占用都不高，但是通過命令
重慶分公司
重慶分公司
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'發(fā)現(xiàn)有大量的CLOSE_WAIT端口占用，繼續(xù)調(diào)用該服務(wù)的api，等待超時(shí)之后發(fā)現(xiàn)CLOSE_WAIT的數(shù)量也沒有上升，也就是說服務(wù)幾乎完全僵死。
懷疑可能是線程有死鎖，決定先dump一下線程情況，執(zhí)行
jstack> /tmp/thread.hump
發(fā)現(xiàn)tomcat線程基本也正常，都是parking狀態(tài)。
這就比較奇怪了，繼續(xù)想是不是GC導(dǎo)致了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
一看嚇一跳，F(xiàn)GC的次數(shù)居然超過了YGC，時(shí)長有475s。一定是有什么原因觸發(fā)了FGC，好在我們打開了GC log。
發(fā)現(xiàn)一段時(shí)間內(nèi)頻繁發(fā)生Allocation Failure引起的Full GC。而且eden區(qū)的使用占比也很大，考慮有頻繁新建對象逃逸到老年代造成問題。詢問了一下業(yè)務(wù)的開發(fā)，確認(rèn)有一個(gè)外部對接API沒有分頁，查詢后可能會產(chǎn)生大量對象。
由于外部API暫時(shí)無法聯(lián)系對方修改，所以為了先解決問題，對原有的MaxNewSize進(jìn)擴(kuò)容，從192MB擴(kuò)容到一倍。經(jīng)過幾天的觀察，發(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
擴(kuò)容之前對heap進(jìn)行了dump
jmap -dump:format=b,file=heapDump
通過MAT分析內(nèi)存泄露，居然疑似是jdbc中的一個(gè)類，但其實(shí)整體占用堆容量并不多。
分析了線程數(shù)量，大約是240多條，與正常時(shí)也并沒有很大的出入。而且大量的是在sleep的定時(shí)線程。
本次排查其實(shí)并未找到真正的原因，間接表象是FGC頻繁導(dǎo)致服務(wù)假死。而且acturator端口是正常工作的，導(dǎo)致health check進(jìn)程誤認(rèn)為服務(wù)正常，沒有觸發(fā)告警。如果你也遇到類似的情況歡迎一起討論。
關(guān)于Spring Boot假死診斷的實(shí)例分析問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。
