線程堆棧快照：為線程命名，洞察 JVM 運行狀態

為什麼 IDE 調試器不適合多線程伺服器程式？

圖形化 IDE 的調試工具擅長單線程 GUI 應用，但難以應對多線程 Java 伺服器程式的動態並發行為。幸運的是，我們擁有強大的診斷工具：日誌 API（如 Log4j）、Java Debugger (jdb)、以及最直接的線程堆棧快照。

獲取線程堆棧快照

在伺服器運行時，於終端按 Ctrl+\（Windows/Linux）或發送 SIGQUIT 信號（`kill -3 `），JVM 將輸出所有線程的完整堆棧資訊。範例輸出：

Full thread dump:
"Thread-1" prio=5 tid=0x87fe0 nid=0x800013b8 waiting on monitor [0..0xbfffe9f8]
"Thread-0" prio=5 tid=0xafde0 nid=0x72a00 runnable [0x173f000..0x173fb48]
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:421)
    at java.net.ServerSocket.implAccept(ServerSocket.java:243)
    at java.net.ServerSocket.accept(ServerSocket.java:222)
    at com.generationjava.net.PortListener.run(PortListener.java:38)
    at java.lang.Thread.run(Thread.java:496)
"Signal Dispatcher" daemon prio=10 tid=0xa5f80 nid=0x52af0 waiting on monitor [0..0]
"Finalizer" daemon prio=8 tid=0xa46c0 nid=0x4d930 waiting on monitor [0x10a8000..0x10a8b48]
    at java.lang.Object.wait(Native Method)
    ...
"VM Thread" prio=5 tid=0xa2de0 nid=0x4ca20 runnable
"VM Periodic Task Thread" prio=10 tid=0xa56b0 nid=0x52890 waiting on monitor

後四條為 JVM 內建守護線程，前兩條為應用程式線程，預設命名為 Thread-0、Thread-1，難以識別業務用途。

為線程賦予有意義的名稱

建立線程時指定名稱，或事後調用 setName()：

// 建立時命名
Thread th = new Thread(runnable, "Server-Listener");

// 或後續命名
thread.setName("Order-Processor-" + orderId);

再次獲取堆棧時，輸出將變為：

"Server-Listener" prio=5 tid=0xafde0 nid=0x72a00 runnable [0x173f000..0x173fb48]
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    ...

原 Thread-1 變為 Thread-0，但關鍵業務線程已清晰可辨。

線程堆棧的診斷價值

• 死鎖偵測：多次快照對比，若線程長期處於 waiting on monitor 且持有鎖，疑似死鎖。
• 效能瓶頸：高 CPU 線程的堆棧顯示熱點方法（如頻繁 GC、正則匹配、同步阻塞）。
• 資源洩漏：線程數異常增長，可能未正確關閉線程池或資料庫連線。
• 業務追蹤：配合有意義名稱，快速定位特定業務流程（如「Payment-Callback」）的執行進度。

進階：結合工具深度分析

線程堆棧是靜態快照，動態分析需結合：

• VisualVM / JConsole：圖形化監控線程狀態、堆記憶體、CPU 使用率。
• jstack：命令列工具，支援輸出至檔案離線分析（`jstack -l > threaddump.txt`）。
• Java Flight Recorder (JFR)：低開銷持續記錄，事後分析線程行為時間線。

掌握線程命名與堆棧分析，是 Java 伺服器端開發者排查生產環境疑難雜症的必備技能。