jstack 線程堆棧分析實戰：定位死鎖、CPU 飆高、卡頓根因

什麼是 jstack？

jstack 是 JDK 自帶的線程堆棧快照工具，輸出 JVM 當前所有線程的調用棧，是生產環境故障排查的「核磁共振」。

核心參數

實操步驟

1. 獲取進程 PID

# Linux/Mac
jps -l  # 列出所有 Java 進程
ps -ef | grep java

# Windows 任務管理器 → 詳情 → 勾選 PID 列

2. 生成堆棧文件

# 推薦：導出文件離線分析
jstack -l  > thread_dump_$(date +%Y%m%d_%H%M%S).log

# 連續抓取 3 次，間隔 10 秒（觀察線程狀態變化）
for i in {1..3}; do jstack -l  > dump_$i.log; sleep 10; done

3. 關鍵線程狀態解讀

四大經典故障排查模式

1. 死鎖定位

搜索關鍵字：Found one Java-level deadlock 或手動分析：

"Thread-1" waiting for <0x000000076c1b2c38> (a java.lang.Object)
    at DeadlockDemo$1.run(DeadlockDemo.java:21)
    - waiting to lock <0x000000076c1b2c38>
    - locked <0x000000076c1b2c48>
"Thread-2" waiting for <0x000000076c1b2c48> (a java.lang.Object)
    at DeadlockDemo$2.run(DeadlockDemo.java:31)
    - waiting to lock <0x000000076c1b2c48>
    - locked <0x000000076c1b2c38>

判斷：Thread-1 持有鎖 A 等鎖 B，Thread-2 持有鎖 B 等鎖 A → 死鎖。

2. CPU 100% 熱點定位

1. top -H -p 找出佔用 CPU 最高的線程 ID (LWP)，如 12345
2. 轉十六進制：printf '%x\n' 12345 → 0x3039
3. 在 jstack 中搜 nid=0x3039，定位該線程棧
4. 分析 RUNNABLE 狀態下的方法調用鏈，找到熱點代碼行

3. 接口響應慢/卡頓

• 搜索 BLOCKED 線程：被誰阻塞？鎖在哪行代碼？
• 搜索 WAITING/TIMED_WAITING：等待什麼資源？DB 連接池？HTTP 調用？鎖？
• 關注 java.net.SocketInputStream.socketRead0 → 網絡 I/O 等待

4. 線程泄漏

對比不同時刻的 dump，線程數持續增長且名稱相似（如 Thread-12345、pool-5-thread-1），檢查：

• 線程池未正確 shutdown
• ThreadLocal 未清理導致線程無法回收
• 第三方庫啟動守護線程未關閉

輔助分析工具

• fastThread：在線分析器，上傳 dump 自動生成報告（推薦）
• Thread Dump Analyzer (TDA)：Swing 桌面工具，圖形化展示
• Arthas：阿里開源 Java 診斷神器，thread -b 自動檢測阻塞鏈
• VisualVM / JConsole：JDK 自帶圖形化監控，可載入 dump 文件

最佳實踐清單

1. 定期備份：生產環境故障前抓 3 次 dump（間隔 10s），保留現場。
2. 命名線程：new Thread(task, "Order-Process-Worker")，dump 中一眼識別業務。
3. 記錄 PID 映射：部署腳本輸出 PID 到文件，故障時秒級定位。
4. 結合業務日誌：dump 只告訴「在哪裡」，日誌告訴「為什麼在那裡」。
5. 學會看鎖地址：-l 參數輸出的 locked <0x...> 是定位鎖競爭關鍵。