jstack是用于诊断java应用线程问题的关键工具，它通过生成线程转储帮助分析死锁、cpu占用高及线程等待等问题。1. 使用jps获取java进程pid；2. 执行jstack pid生成线程转储文件；3. 分析转储中的线程状态与堆栈信息，查找死锁或性能瓶颈。线程状态如blocked、waiting等提示不同问题，结合top命令可定位高cpu占用线程，jstack末尾会自动报告检测到的死锁。远程使用需配置jmx参数并借助jconsole或visualvm连接。
jstack是Java开发和运维中一个非常重要的工具，它可以帮助我们诊断Java应用程序的线程问题。简单来说，jstack可以打印出指定Java进程的线程堆栈信息，让我们了解线程都在做什么，从而找出死锁、长时间等待、CPU占用过高等问题。
线程转储，也称为线程快照或线程dump，是指在某一时刻JVM中所有线程的状态信息。通过分析线程转储，我们可以深入了解应用程序的内部运行情况。
解决方案
使用jstack非常简单，只需要知道Java进程的ID（PID）。
立即学习“Java免费学习笔记（深入）”；
-
找到Java进程的PID： 可以使用
jps命令（Java Virtual Machine Process Status Tool）来列出当前系统上运行的所有Java进程及其PID。例如：jps
输出类似：
12345 MyApplication 67890 AnotherApp
这里的
12345和67890就是PID。 -
使用jstack生成线程转储： 找到PID后，就可以使用jstack命令了。例如，要生成PID为
12345的进程的线程转储，可以执行：jstack 12345 > thread_dump.txt
这条命令会将线程转储信息输出到
thread_dump.txt文件中。 -
分析线程转储： 线程转储文件包含了大量的信息，需要仔细分析才能找到问题。常用的分析方法包括：
- 查找死锁： jstack会自动检测死锁，并在线程转储的末尾报告。
-
查找CPU占用高的线程： 可以结合
top命令（Linux）或任务管理器（Windows）找到CPU占用高的Java进程，然后使用jstack生成线程转储，找出具体的线程。 -
查找长时间等待的线程： 关注线程状态为
BLOCKED或WAITING的线程，看看它们都在等待什么资源。 - 分析线程堆栈： 仔细阅读线程的堆栈信息，了解线程正在执行的代码。
如何解读jstack输出中的线程状态？
jstack输出中，每个线程都有一个状态。理解这些状态对于分析线程转储至关重要。常见的线程状态包括：
- NEW: 线程刚被创建，还没有开始执行。
- RUNNABLE: 线程正在运行或准备运行。这并不意味着线程一定在占用CPU，它也可能在等待CPU时间片。
- BLOCKED: 线程被阻塞，正在等待获取锁。这通常是死锁或锁竞争激烈的表现。
-
WAITING: 线程正在等待另一个线程执行特定的动作。例如，调用
Object.wait()方法的线程会进入WAITING状态，直到被Object.notify()或Object.notifyAll()唤醒。 -
TIMED_WAITING: 线程正在等待一段时间。与WAITING状态类似，但指定了等待的超时时间。例如，调用
Thread.sleep()方法的线程会进入TIMED_WAITING状态。 - TERMINATED: 线程已经执行完毕。
不同状态意味着不同的问题，需要根据具体情况进行分析。比如，大量的BLOCKED线程可能意味着锁竞争过于激烈，需要优化锁的使用方式。
jstack能否远程连接到Java进程？
默认情况下，jstack只能连接到本地的Java进程。如果需要远程连接，需要配置JMX（Java Management Extensions）。JMX允许远程监控和管理Java应用程序。
配置JMX的步骤如下：
-
在Java启动参数中添加JMX配置： 需要在Java应用程序的启动脚本中添加一些参数，例如：
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9010 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
这些参数的含义如下：
-
-Dcom.sun.management.jmxremote: 启用JMX远程管理。 -
-Dcom.sun.management.jmxremote.port: 指定JMX的端口号。 -
-Dcom.sun.management.jmxremote.ssl: 是否启用SSL加密。 -
-Dcom.sun.management.jmxremote.authenticate: 是否启用认证。
注意： 在生产环境中，强烈建议启用SSL加密和认证，以确保安全性。
-
-
使用jconsole或VisualVM等JMX客户端连接到远程Java进程： 启动Java应用程序后，可以使用jconsole或VisualVM等JMX客户端连接到远程Java进程，并使用jstack功能生成线程转储。
例如，在jconsole中，选择“远程进程”，输入
hostname:port（例如192.168.1.100:9010），然后点击“连接”。连接成功后，就可以在“线程”选项卡中查看线程信息，并生成线程转储。
如何利用jstack定位CPU占用率高的线程？
当Java应用程序的CPU占用率很高时，可以使用jstack来定位是哪个线程导致的。步骤如下：
使用
top命令（Linux）或任务管理器（Windows）找到CPU占用率高的Java进程： 例如，在Linux中，可以使用top命令查看CPU占用率最高的进程。找到占用CPU最高的线程ID： 在
top命令的输出中，按H键可以显示线程级别的CPU占用率。找到占用CPU最高的线程ID（PID）。将线程ID转换为十六进制： 线程ID是十进制的，需要转换为十六进制才能在jstack的输出中查找。可以使用计算器或编程语言进行转换。例如，如果线程ID是
12345，转换为十六进制就是3039。使用jstack生成线程转储： 使用jstack命令生成Java进程的线程转储。
在线程转储中查找线程ID（十六进制）： 在线程转储文件中，查找包含线程ID（十六进制）的行。找到对应的线程信息。
分析线程堆栈： 仔细阅读线程的堆栈信息，了解线程正在执行的代码，从而找出导致CPU占用率高的原因。
举个例子，假设top命令显示Java进程的PID是12345，线程ID是67890，转换为十六进制是10862。在线程转储文件中，找到类似这样的行：
"Thread-1" #23 prio=5 os_prio=0 tid=0x00007f2a48c1a000 nid=0x10862 runnable [0x00007f2a459b6000]
java.lang.Thread.State: RUNNABLE
at com.example.MyClass.myMethod(MyClass.java:100)
at com.example.MyClass.run(MyClass.java:50)
at java.lang.Thread.run(Thread.java:745)这表示线程Thread-1（线程ID为0x10862）正在执行com.example.MyClass.myMethod方法，并且该方法位于MyClass.java文件的第100行。如果这个方法包含了大量的计算或者死循环，就可能导致CPU占用率很高。
如何使用jstack检测死锁？
jstack可以自动检测死锁，并在线程转储的末尾报告。
使用jstack生成线程转储： 使用jstack命令生成Java进程的线程转储。
-
查看线程转储的末尾： 在线程转储文件的末尾，jstack会尝试检测死锁。如果检测到死锁，会输出类似这样的信息：
Found one Java-level deadlock: ============================= "Thread-1": waiting to lock monitor 0x00007f2a490018a8 (object 0x000000076c123456, a com.example.MyClass), which is held by "Thread-2" "Thread-2": waiting to lock monitor 0x00007f2a490020b8 (object 0x000000076c789012, a com.example.AnotherClass), which is held by "Thread-1" Java stack information for the threads listed above: =================================================== "Thread-1": at com.example.MyClass.myMethod(MyClass.java:100) - waiting to lock <0x000000076c123456> (a com.example.MyClass) at com.example.MyClass.run(MyClass.java:50) at java.lang.Thread.run(Thread.java:745) "Thread-2": at com.example.AnotherClass.anotherMethod(AnotherClass.java:200) - waiting to lock <0x000000076c789012> (a com.example.AnotherClass) at com.example.AnotherClass.run(AnotherClass.java:80) at java.lang.Thread.run(Thread.java:745) Found 1 deadlock.这段信息表明，
Thread-1正在等待Thread-2持有的锁，而Thread-2正在等待Thread-1持有的锁，从而导致了死锁。 分析线程堆栈： 仔细阅读线程的堆栈信息，了解线程在哪些代码中获取了锁，以及在哪些代码中等待锁，从而找出死锁的原因。
分析死锁需要一定的经验，但jstack的死锁检测功能可以大大简化这个过程。
