jstack用于生成java虛擬機(jī)當(dāng)前時(shí)刻的線程快照。線程快照是當(dāng)前java虛擬機(jī)內(nèi)每一條線程正在執(zhí)行的方法堆棧的集合，生成線程快照的主要目的是定位線程出現(xiàn)長時(shí)間停頓的原因，如線程間死鎖、死循環(huán)、請求外部資源導(dǎo)致的長時(shí)間等待等。?
線程出現(xiàn)停頓的時(shí)候通過jstack來查看各個(gè)線程的調(diào)用堆棧，就可以知道沒有響應(yīng)的線程到底在后臺做什么事情，或者等待什么資源。
如果java程序崩潰生成core文件，jstack工具可以用來獲得core文件的java stack和native stack的信息，從而可以輕松地知道java程序是如何崩潰和在程序何處發(fā)生問題。
另外，jstack工具還可以附屬到正在運(yùn)行的java程序中，看到當(dāng)時(shí)運(yùn)行的java程序的java stack和native stack的信息, 如果現(xiàn)在運(yùn)行的java程序呈現(xiàn)hung的狀態(tài)，jstack是非常有用的。
IBM提供的分析javacore和dump的內(nèi)存分析工具，非常好用。
IBM Thread and Monitor Dump Analyzer for Java (TMDA) 是允許識別 Java 線程轉(zhuǎn)儲中的掛起、死鎖、資源爭用和瓶頸的工具。
IBM Thread and Monitor Dump Analyzer for Java (TMDA)
https://www.ibm.com/support/pages/ibm-thread-and-monitor-dump-analyzer-java-tmda
https://public.dhe.ibm.com/software/websphere/appserv/support/tools/jca/jca4611.jar
在 Linux 等基于 POSIX 的系統(tǒng)上請求線程轉(zhuǎn)儲的最簡單方法是發(fā)送 kill -3 信號，該信號非破壞性地暫停 JVM，創(chuàng)建線程轉(zhuǎn)儲，然后 JVM 繼續(xù)（暫停通常是幾百毫秒）。
例如（將 ${PID} 替換為 Java 進(jìn)程的進(jìn)程 ID）：
$?kill -3? $PID
在 Java? 進(jìn)程的運(yùn)行時(shí)，它可能無法做出可預(yù)測的響應(yīng)，并且可能會掛起很長時(shí)間或直到 JVM 關(guān)閉，確定此類問題的根本原因并不容易。
通過在 Java 進(jìn)程未響應(yīng)時(shí)觸發(fā)一個(gè)或多個(gè)線程轉(zhuǎn)儲，可以收集與 JVM 相關(guān)的診斷信息以及在執(zhí)行期間在特定點(diǎn)捕獲的 Java 應(yīng)用程序（請注意，Java 速度變慢的另一個(gè)常見原因是垃圾收集，在在這種情況下，您應(yīng)該查看詳細(xì)的垃圾收集）。
例如，信息可以是關(guān)于操作系統(tǒng)、應(yīng)用程序環(huán)境、線程、本機(jī)堆棧、鎖和內(nèi)存，確切的內(nèi)容取決于運(yùn)行應(yīng)用程序的平臺和 JVM。
這是 TMDA 的屏幕截圖，顯示單個(gè)線程轉(zhuǎn)儲（左半部分顯示線程轉(zhuǎn)儲中的所有線程），按堆棧深度降序排序（因?yàn)槎褩Ｉ疃韧ǔＥc非空閑相關(guān)），并顯示可疑的線程堆棧（右半部分）。
在Thread Dump List中右鍵可以查看Thread詳細(xì)信息。
在IBM Thread and Monitor Dump Analyzer for Java工具中，請求線程可分為以下幾種狀態(tài)：
1.死鎖，Deadlock（重點(diǎn)關(guān)注）
2.執(zhí)行中，Runnable（重點(diǎn)關(guān)注）
3.等待資源，Waiting on condition（重點(diǎn)關(guān)注）
4.等待監(jiān)控器檢查資源，Waiting on monitor
5.暫停，Suspended
6.對象等待中，Object.wait()
7.阻塞，Blocked（重點(diǎn)關(guān)注）
8.停止，Parked
Deadlock：死鎖線程：一般指多個(gè)線程調(diào)用間，進(jìn)入相互資源占用，導(dǎo)致一直等待無法釋放的情況。
Runnable：一般指該線程正在執(zhí)行狀態(tài)中，該線程占用了資源，正在處理某個(gè)請求，有可能正在傳遞SQL到數(shù)據(jù)庫執(zhí)行，有可能在對某個(gè)文件操作，有可能進(jìn)行數(shù)據(jù)類型等轉(zhuǎn)換。
Waiting on condition：等待資源，如果堆棧信息明確是應(yīng)用代碼，則證明該線程正在等待資源，一般是大量讀取某資源，且該資源采用了資源鎖的情況下，線程進(jìn)入等待狀態(tài)，等待資源的讀取,又或者正在等待其他線程的執(zhí)行等。
Blocked：線程阻塞，是指當(dāng)前線程執(zhí)行過程中，所需要的資源長時(shí)間等待卻一直未能獲取到，被容器的線程管
在某些平臺上，在某些情況下，javacores 被稱為 javadumps，創(chuàng)建 javacore 的代碼是 JVM 的一部分。
你可以通過使用環(huán)境變量和命令行參數(shù)來控制它。
默認(rèn)情況下，當(dāng) JVM 意外終止時(shí)會發(fā)生 javacore，也可以通過向 JVM 發(fā)送特定信號來觸發(fā) javacore。
盡管 HotSpot JVM 中存在線程轉(zhuǎn)儲（發(fā)送到 stderr 而不是 javacore.txt 文件），但 J9 JVM（IBM Java、OpenJ9）生成的 javacore 的內(nèi)容要豐富得多。
該工具分析每個(gè)線程并提供診斷信息，例如當(dāng)前線程信息、導(dǎo)致 javacore 的信號、Java 堆信息（最大 Java 堆大小、初始 Java 堆大小、垃圾收集器計(jì)數(shù)器、分配失敗計(jì)數(shù)器、空閑 Java 堆大小和分配的 Java 堆大?。?、可運(yùn)行線程數(shù)、線程總數(shù)、鎖定的監(jiān)視器數(shù)和死鎖信息。
IBM Thread and Monitor Dump Analyzer for Java 比較每個(gè) javacore 并提供線程的進(jìn)程 ID 信息、第一個(gè) javacore 的時(shí)間戳、最后一個(gè) javacore 的時(shí)間戳、每分鐘垃圾收集次數(shù)、每分鐘分配失敗次數(shù)、第一個(gè) javacore 和最后一個(gè) javacore、掛起嫌疑人的數(shù)量和掛起嫌疑人列表。
此工具還比較 javacores 中的所有監(jiān)視器信息，并檢測死鎖和資源爭用或監(jiān)視器瓶頸（如果有）。
TMDA 工具按原樣提供，不提供任何保證或支持；但是，我們會在時(shí)間允許的情況下嘗試修復(fù)和增強(qiáng)該工具。該工具最初由 Jinwoo Hwang 創(chuàng)建。自從 Hwang 先生離開 IBM 后，Kevin Grigorenko ( kevin.grigorenko@us.ibm.com )在時(shí)間允許的情況下維護(hù)該工具。
參考
Online Java Thread Dump Analyzer
http://spotify.github.io/threaddump-analyzer
Jstack分析工具——IBM Thread and Monitor Dump Analyzer for Java
https://blog.csdn.net/aovenus/article/details/116244885
Java進(jìn)程故障排查思路及步驟
https://www.likecs.com/show-306377648.html
Java Thread Dump Analyzer
https://gceasy.io/ft-index.jsp
面試官：如果你們的系統(tǒng) CPU 突然飆升且 GC 頻繁，如何排查？
https://mp.weixin.qq.com/s/g8KJhOtiBHWb6wNFrCcLVg
通過JVM堆棧分析出現(xiàn)大量線程的原因
http://www.crazyant.net/1858.html
jstack線程快照-線程狀態(tài)及線程堆棧信息
https://blog.csdn.net/CJQ316210/article/details/121980023
