Java 死鎖排查實戰：Thread Dump 分析與鎖鏈追踪全流程

為什麼 Thread Dump 是分析死鎖的黃金標準？

• 跨平台：Linux/Windows/Mac 均支持
• 生產環境安全：開銷極小，不干擾業務
• 直達代碼：堆棧直接對應 Java 源碼行號
• 靜態快照：死鎖時 JVM 掛起，Dump 信息穩定可靠

對比：Profiling 工具侵入性大、改變時序、不可用於生產；OS 工具（top/prstat）只見 CPU 佔用，不見 Java 鎖邏輯。

獲取 Thread Dump 三大方式

死鎖特徵識別：兩步驟法

步驟 1：尋找「waiting for monitor entry」

大量線程等待同一把鎖（同一對象地址）是死鎖強信號：

"service-j2ee" prio=5 tid=0x024f1c28 nid=0x125 waiting for monitor entry
...
- waiting to lock <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)

步驟 2：確認持鎖線程狀態

隔 1-2 分鐘再取一次 Dump，若等待線程集合不變，確認死鎖。搜索 locked <0x965d8110> 找到持鎖線程：

"Thread-20" daemon prio=5 tid=0x01394f18 nid=0x109 runnable
...
- locked <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)
at com.sun.enterprise.resource.IASNonSharedResourcePool.resizePool(...)
...
at java.net.SocketInputStream.socketRead0(Native Method)
...
at oracle.net.ns.NetInputStream.read(...)

結論：持鎖線程在等待 Oracle 數據庫響應（網絡讀阻塞），導致連接池縮容鎖長期不釋放，引發級聯死鎖。

鎖鏈追踪：順藤摸瓜

若持鎖線程又在等待另一把鎖（waiting to lock <0x...>），繼續搜索該地址的 locked，直到找到根因（通常是 I/O 阻塞、無限循環、外部系統無響應）。

特殊線程狀態解讀

"Thread-1" daemon ... in Object.wait()
- waiting on <0x95b07178> (a java.util.LinkedList)
- locked <0x95b07178> (a java.util.LinkedList)
at com.iplanet.ias.util.collection.BlockingQueue.remove(...)

此線程主動 wait() 釋放鎖，等待條件（隊列非空）。分析重點：等待條件是否會被滿足？ 若生產者掛起，消費者永久等待。

進階工具：jstack 與 jconsole

• jstack -l <PID>：打印鎖信息（java.util.concurrent.locks 也可見）
• jconsole：圖形化檢測 Object Monitor 和 JUC Locks 死鎖，支持導出
• jvisualvm + Threads 插件：時間軸視圖，更直觀

生產環境排查清單

1. 獲取 3 次 Dump（間隔 30s），確認線程狀態不變
2. 統計 BLOCKED/WAITING 線程數，識別熱點鎖
3. 定位持鎖線程代碼行，分析業務邏輯
4. 檢查外部依賴（DB、RPC、MQ）響應超時/掛起
5. 檢查代碼：鎖順序一致性、超時機制、連接池配置

總結

Thread Dump 是 Java 死鎖排查的「核磁共振」。掌握 waiting for monitor entry ↔ locked 雙向追踪，配合多次快照對比，能精準定位 99% 的死鎖根因。建議將 Dump 分析納入事故應急預案，關鍵系統部署 jstack 定時采集腳本，做到有備無患。