Thread Dump 是 JVM 當前所有線程堆棧的快照，是排查 CPU 飆高、死鎖、內存洩漏、響應變慢、線程飢餓 等問題的「核磁共振」。掌握多種獲取方式，應對不同環境限制（無 JDK、無權限、容器化、Windows 等）。
| 方法 | 適用場景 | 優點 | 缺點 |
|---|---|---|---|
| jstack | 有 JDK、本地/遠程進程 | 官方標準、輕量、可腳本化 | 需 JDK、進程同用戶 |
| kill -3 | 僅 JRE、Linux/Unix | 無需 JDK、容器友好 | 輸出到 stdout、難重定向 |
| jvisualvm | 桌面開發、可視化分析 | GUI 直觀、支持遠程、含概覽 | 需圖形界面、啟動慢 |
| JMC (Flight Recorder) | 生產環境持續分析 | 低開銷、歷史回溯、事件豐富 | 需商業授權(舊版)、學習曲線 |
| Ctrl+Break | Windows 控制台程序 | 無工具、即時 | 輸出到控制台、難保存 |
| ThreadMXBean | 應用內嵌、程序化導出 | 無外部依賴、可集成監控端點 | 需修改代碼、重新部署 |
| APM 工具 | 全鏈路監控體系 | 一鍵獲取、關聯調用鏈、告警聯動 | 需部署探針、成本高 |
# 基礎用法
jstack -l > threadDump.txt
# -l: 長列表，包含鎖信息 (java.util.concurrent locks)
# 容器內獲取 (Docker)
docker exec jstack -l 1 > /tmp/dump.txt
# 遠程獲取 (需同用戶、同網絡)
jstack -l @ > dump.txt
注意：JDK 5+ 內置。若進程掛起無響應，加 -F 強制 (僅限 Linux/Solaris)。
kill -3
# 輸出導向：進程 stdout (如 Tomcat 為 catalina.out)
# 容器中: kubectl exec -- kill -3 1
輸出格式與 jstack 一致，但混雜在應用日誌中，需提取。
JDK_HOME/bin/jvisualvm.exe，雙擊進程 →「線程 Dump」按鈕，支持保存文件、篩選、死鎖檢測JDK_HOME/bin/jmc.exe，啟動 Flight Recorder → 設置 Dump 間隔 (如 60s) → Threads 面板查看歷史快照java MyApp > dump.txt 2>&1 後再觸發public void dumpThreadDump() {
ThreadMXBean mx = ManagementFactory.getThreadMXBean();
for (ThreadInfo ti : mx.dumpAllThreads(true, true)) { // locked monitors, locked synchronizers
System.out.println(ti);
}
}
// 暴露為 HTTP 端點 (Spring Boot Actuator /management/threaddump)
優勢：無外部工具、可集成到運行時管理後台、支持定時自動導出。
fastthread.io、thread-analyzer 等在線工具上傳分析jstack (側車容器) 或 kill -3 (kubectl exec)，避免進入容器交互jstack -l 末尾自動報告 "Found one Java-level deadlock"七大方法中，jstack 與 kill -3 覆蓋 95% 場景，建議作為標準 SOP 納入故障應急手冊。可視化工具適合深度分析，程序化接口適合自動化運維，APM 適合全鏈路關聯。無論哪種方式，連續多次抓取、保存原始文本、關聯上下文 是高效定位問題的鐵律。
