Labs 導讀

作為Java開發(fā)者，在日常工作中經(jīng)常會碰到Java服務(wù)端程序無法響應(yīng)客戶端的請求，輕則影響用戶體驗，重則會造成重大故障。這種無法響應(yīng)客戶端的請求就是常說的服務(wù)“假死”、“卡住了”。那么，在這種“假死”的背后到底發(fā)生了什么事，本該正常響應(yīng)客戶端請求的進程、線程又在做什么呢？本文帶你來揭曉這一答案。

Part 01、 程序“假死”的跡象  

服務(wù)端程序卡死之后，最常見的現(xiàn)象是無法響應(yīng)客戶端請求，結(jié)果返回特別慢直至超時。如果是網(wǎng)頁服務(wù)，那么用戶會發(fā)現(xiàn)該頁面會無法訪問，或者一直加載不出來。

如果此時深入查看Http協(xié)議，其返回狀態(tài)碼一般是504（Gateway Timeout），提示網(wǎng)關(guān)超時。如果該程序?qū)?yīng)的進程還在存活在操作系統(tǒng)中，在排除了網(wǎng)絡(luò)、服務(wù)器問題后，可以認為該程序已經(jīng)“假死”，無法再繼續(xù)提供服務(wù)。有些程序在假死后過一段時間可以自己恢復，然而更多的時候需要人工介入重啟程序才能恢復正常。

Part 02、如何定位假死問題 

接下來我們看一下當碰到程序假死問題時，應(yīng)該從哪些方面著手處理，如何快速定位到根本原因。

2.1 常用的工具

工欲善其事必先利其器，我們首先來看下一些常用的診斷問題的工具。

2.1.1 top命令

top命令是Linux下常用的性能分析工具，能夠?qū)崟r顯示系統(tǒng)中各個進程的資源占用狀況，操作系統(tǒng)自帶。在終端中輸入top即可看到正在運行的所有進程占用的CPU、內(nèi)存、運行時間等，也能夠大致知曉當前服務(wù)器的運行狀態(tài)。

top命令結(jié)果

以上是一張典型的top命令結(jié)果圖，可以看出java進程進行占用了 44.7%的內(nèi)存，118.8%的CPU（多核的CPU使用率會超過100%），但系統(tǒng)1分鐘的平均負載（load average）只有0.92，運行較為穩(wěn)定。

2.1.2 jstat命令

jstat 是用于監(jiān)控虛擬機各種運行狀態(tài)信息的命令行工具，包括了對Heap size和垃圾回收狀況的監(jiān)控，由JDK提供。當需要了解JVM的運行狀態(tài)時它是首選工具。比如需要每秒查看一次JVM的垃圾回收狀態(tài)，可以使用：

jstat命令結(jié)果

上圖是進程號為4417的JVM進程的內(nèi)存使用情況，S0和S1是新生代中幸存區(qū)使用比例，E是伊甸園區(qū)空間使用比例，O是老年代空間使用比例；YGC是新生代垃圾回收次數(shù)，YGCT是新生代垃圾回收總時間；FGC是老年代垃圾回收次數(shù)，F(xiàn)GCT是老年代垃圾回收總時間，GCT是垃圾回收總時間。當出現(xiàn)內(nèi)存不夠用時，O會出現(xiàn)100%，并且FGC和FGCT持續(xù)增加，比較容易辨別。

2.1.3 jmap命令

jmap是JDK提供的一個可以生成JVM的堆轉(zhuǎn)儲快照dump文件的命令行工具。除此以外，jmap命令還可以查看finalize執(zhí)行隊列、Java堆和方法區(qū)的詳細信息，比如空間使用率、當前使用的什么垃圾回收器、分代情況等等。當出現(xiàn)內(nèi)存問題時，就需要jmap命令將內(nèi)存堆轉(zhuǎn)儲成文件進行詳細的分析了。常用的命令如下：

該命令將堆轉(zhuǎn)儲成名為memory.hprof的文件，后續(xù)可以使用堆內(nèi)存分析工具（如Eclipse Memory Analyzer）等進行詳細分析，在此不再展開。

2.1.4 jstack命令

jstack是JDK提供的一個可以生成JVM當前時刻的線程快照信息的命令行工具，可以探查在命令執(zhí)行那一刻JVM中每個線程都在做什么。在實際使用中，可以每隔10秒鐘執(zhí)行一次，連續(xù)執(zhí)行幾次再對比分析，實際中的輸出內(nèi)多會比較多，建議轉(zhuǎn)存到文件中方便分析。常用的命令如下：

jstack命令部分結(jié)果

上圖是jstack命令的部分結(jié)果，顯示名為logback-8的線程此刻正在等待狀態(tài)，未執(zhí)行實際的任務(wù)。

2.2 診斷三把斧

JVM進程假死其實就是線程不夠用了，忙不過來，用以下三把斧依次施行，基本上能夠覆蓋90%以上場景。

2.2.1 看進程

首先，使用top命令對服務(wù)器的負載和進程的資源使用做一個評估。尤其關(guān)注top命令中的負載指標和進程的CPU、內(nèi)存使用率。負載代表服務(wù)器的繁忙程度，它綜合了CPU、IO等指標，負載/CPU數(shù) > 1 代表服務(wù)器非常繁忙。當系統(tǒng)負載高時，而每一個進程的CPU都不高時，要考慮服務(wù)器是否已經(jīng)過載，比如運行進程過多、IO瓶頸等。當某個進程的CPU使用高時，問題大概率出在該進程中，即可對該進程進行探查。（本文只討論JVM，故進程特指JVM進程）

2.2.2 看內(nèi)存

使用jstat命令查看JVM的內(nèi)存狀態(tài)。當JVM內(nèi)存泄漏導致堆內(nèi)存無法回收、堆內(nèi)存不夠用從而觸發(fā)頻繁的Full GC時，JVM會停頓程序的執(zhí)行進行全面的垃圾回收（stop the world），此時程序?qū)o法響應(yīng)請求，GC線程會占用大量的CPU時間。當這種情況發(fā)生時，會出現(xiàn)進程CPU使用率很高，接近系統(tǒng)極限。堆內(nèi)存中老年代空間使用比例接近或達到100%，F(xiàn)GC、FGCT在持續(xù)地上升（正常情況下Full GC幾小時甚至幾天才執(zhí)行一次）。

當判斷為進程因內(nèi)存問題而一直在Full GC時，可以使用jmap命令將內(nèi)存dump下來進行進一步的分析，查找內(nèi)存泄漏的對象，進而進一步找到內(nèi)存泄漏點。此外，值得注意的一點是如果堆內(nèi)存本身設(shè)得很小，而程序需要的內(nèi)存又很多，JVM會嘗試去回收內(nèi)存，也會出現(xiàn)頻繁的Full GC而導致CPU使用率升高的情況。這就需要具體問題具體分析了。

2.2.3 看線程

使用jstack命令查看線程狀態(tài)。當操作系統(tǒng)、堆內(nèi)存都無明顯異常情況下，需要進一步探查每一個線程都在做什么。線程無法處理更多任務(wù)，要么是線程都很忙（單核 CPU 100%），要么是都在等待（CPU使用率不高），極少數(shù)是處于死鎖狀態(tài)，而這些都可以從jstack的命令結(jié)果中看出來。

jstack會顯示每個線程當前所處的程序棧。如果多個線程處在同一個程序棧，那么要引起高度注意，可以通過連續(xù)幾個間隔10秒左右的jstack結(jié)果查看該線程是否一直處于同一位置，如果是那么大概率是卡在了這里。如果是死循環(huán)，那么CPU使用率會很高，如果是等待IO，那么CPU使用率會很低。通過卡住的程序棧，可以較容易定位到代碼行并進行進一步的分析了。

Part 03、 案例實戰(zhàn) 

了解完基本的理論知識，下面通過實際工作中碰到的案例來使用三把斧進行分析。

3.1 案例一：IO等待

系統(tǒng)表現(xiàn)：界面無響應(yīng)，請求API也無響應(yīng)。

看進程：top命令顯示系統(tǒng)負載很低，進程CPU、內(nèi)存使用也無異常。

看內(nèi)存：jstat命令顯示堆內(nèi)存表現(xiàn)正常：

jstat顯示堆內(nèi)存狀態(tài)正常

看線程：jstack命令顯示絕大部分線程都卡在同一個地方：

出現(xiàn)io等待的線程

通過進一步檢查AbstractProvinceServiceImpl.sendPost方法，發(fā)現(xiàn)是使用java原生的HttpUrlConnection來實現(xiàn)Http請求的方法，而該方法未設(shè)置超時時間，如果被調(diào)用方未返回會一直等待。

有缺陷的代碼

至此，問題原因查明：因代碼缺陷，在發(fā)起http請求時未設(shè)置超時時間，而恰好此時被調(diào)用方系統(tǒng)故障，無法及時返回，從而導致線程都卡在這里等待IO，無更多的線程來響應(yīng)其他請求了。

3.2 案例二：死循環(huán)

系統(tǒng)表現(xiàn)：系統(tǒng)響應(yīng)很慢，api請求有一定的錯誤率。

看進程：top命令顯示系統(tǒng)負載較高（1核CPU），進程CPU達到190%，系統(tǒng)過載。

負載較高，進程CPU使用率較高

看內(nèi)存：jstat命令顯示堆內(nèi)存表現(xiàn)正常，無明顯的內(nèi)存問題。

看線程：多次間隔執(zhí)行jstack命令，發(fā)現(xiàn)一部分進程一直卡在同一個地方：

出現(xiàn)死循環(huán)的線程

通過查看相關(guān)代碼發(fā)現(xiàn)這里有個死循環(huán)，當變量cur一直不為null時，程序無法跳出循環(huán)。通過更進一步的分析，最終找數(shù)據(jù)庫中的一條數(shù)據(jù)其CateParentId是自己，從而觸發(fā)這個死循環(huán)的bug。

...


while (Objects.nonNull(cur)) { 
    allCateName.insert(0, "/"); 
    allCateName.insert(0, cur.getCateName()); 
    cur = goodsCatePOMap.get(cur.getCateParentId()); 
} 


...

Part 04、  總結(jié) 

對于Java服務(wù)端假死，可以通過本文介紹的三把斧，利用一些常用工具來對程序內(nèi)部的運行狀態(tài)進行分析。掌握這個方法后，基本上可以定位到工作中碰到的90%以上的java程序假死問題。下表是對可能的假死原因做一個簡單的歸納總結(jié)：