jstack：查看当前所有线程的状态和运行情况
 jstack [-option] pid
 Options:
 -F to force a thread dump. Use when jstack does not respond (process is hung)
 -m to print both java and native frames (mixed mode)
 -l long listing. Prints additional information about locks
 
注意事项：
 此处线程id为16进制，10进制转16进制 printf “%x” 十进制 16进制转10进制 printf “%d” 0x十进制数
 
/nemo/jdk/bin/jstack 239637
 
2021-04-12 21:37:29
 Full thread dump Java HotSpot™ 64-Bit Server VM (24.65-b04 mixed mode):
 
“http-bio-8080-exec-320” daemon prio=10 tid=0x00007faa4809e000 nid=0x8eec waiting on condition [0x00007faa60f95000]
 java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for <0x000000074307fa08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:186)atjava.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
 at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
 at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
 at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)atorg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:745)
 
“http-bio-8080-exec-319” daemon prio=10 tid=0x00007faa4809c800 nid=0x8eeb waiting on condition [0x00007faa61ca2000]
 java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for <0x000000074307fa08> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:186)atjava.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
 at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
 at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
 at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)atorg.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 
/nemo/jdk/bin/jstack -m 239637
 
Attaching to process ID 239637, please wait…
 Debugger attached successfully.
 Server compiler detected.
 JVM version is 24.65-b04
 Deadlock Detection:
 
No deadlocks found.
 
----------------- 239638 -----------------
 0x00000039ef80b68c __pthread_cond_wait + 0xcc
 0x00007faa754beaaf _ZN7Monitor5IWaitEP6Threadl + 0xef
 0x00007faa754bf23e _ZN7Monitor4waitEblb + 0x22e
 0x00007faa752339e3 _ZN13GCTaskManager8get_taskEj + 0x43
 0x00007faa752350a8 _ZN12GCTaskThread3runEv + 0x188
 0x00007faa754fd988 _ZL10java_startP6Thread + 0x108
 ----------------- 239639 -----------------
 0x00000039ef80b68c __pthread_cond_wait + 0xcc
 0x00007faa754beaaf _ZN7Monitor5IWaitEP6Threadl + 0xef
 0x00007faa754bf23e _ZN7Monitor4waitEblb + 0x22e
 0x00007faa752339e3 _ZN13GCTaskManager8get_taskEj + 0x43
 0x00007faa752350a8 _ZN12GCTaskThread3runEv + 0x188
 0x00007faa754fd988 _ZL10java_startP6Thread + 0x108
 ----------------- 239640 -----------------
 0x00000039ef80b68c __pthread_cond_wait + 0xcc
 0x00007faa754beaaf _ZN7Monitor5IWaitEP6Threadl + 0xef
 0x00007faa754bf23e _ZN7Monitor4waitEblb + 0x22e
 0x00007faa752339e3 _ZN13GCTaskManager8get_taskEj + 0x43
 0x00007faa752350a8 _ZN12GCTaskThread3runEv + 0x188
 0x00007faa754fd988 _ZL10java_startP6Thread + 0x108
 ----------------- 239641 -----------------

Jstack
 
jstack命令的语法格式： jstack 。可以用jps查看java进程id。这里要注意的是：
 
\1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的，不同的 JVM版本， dump信息也有差别。
 
\2. 在实际运行中，往往一次 dump的信息，还不足以确认问题。建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。
 
jstack Dump 日志文件中的线程状态
 
dump 线程状态
 
死锁， Deadlock（重点关注）
 
执行中，Runnable
 
等待资源， Waiting on condition（重点关注）
 
等待获取监视器， Waiting on monitor entry（重点关注）
 
暂停，Suspended
 
对象等待中，Object.wait() 或 TIMED_WAITING
 
阻塞， Blocked（重点关注）
 
停止，Parked
 
线程状态含义
 
Deadlock：死锁线程，一般指多个线程调用间，进入相互资源占用，导致一直等待无法释放的情况。
 
Runnable：一般指该线程正在执行状态中，该线程占用了资源，正在处理某个请求，有可能正在传递SQL到数据库执行，有可能在对某个文件操作，有可能进行数据类型等转换。
 
Waiting on condition：该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。
 
​ 如果发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几 乎消耗了所有的带宽，仍然有大量数据等待网络读 写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。
 
locked：线程阻塞，是指当前线程执行过程中，所需要的资源长时间等待却一直未能获取到，被容器的线程管理器标识为阻塞状态，可以理解为等待资源超时的线程。
 
Waiting for monitor entry 和 in Object.wait()：Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。
 
C:\Users\srqnk>jstack 8064
2020-07-30 11:25:22
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode):

"DestroyJavaVM" #10 prio=5 os_prio=0 tid=0x00f5cc00 nid=0x1edc waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #9 prio=5 os_prio=0 tid=0x15360400 nid=0x280c waiting for monitor entry [0x159cf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.agree.Exam.ThreadRunB.run(DiedsynchronizedTest.java:42)
        - waiting to lock <0x04ee2840> (a java.lang.Integer)
        - locked <0x04ef8920> (a java.lang.Integer)

"Thread-0" #8 prio=5 os_prio=0 tid=0x1535fc00 nid=0x3968 waiting for monitor entry [0x1593f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.agree.Exam.ThreadRunA.run(DiedsynchronizedTest.java:21)
        - waiting to lock <0x04ef8920> (a java.lang.Integer)
        - locked <0x04ee2840> (a java.lang.Integer)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x152f2800 nid=0x524 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x152c4000 nid=0x960 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x15298000 nid=0x2fe4 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x152c3000 nid=0x1e3c runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x1527a400 nid=0x2718 in Object.wait() [0x1557f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x04e07ee0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x04e07ee0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x15264400 nid=0x2630 in Object.wait() [0x154ef000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x04e05f68> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x04e05f68> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x02c6dc00 nid=0xcb4 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x1533b800 nid=0x5c4 waiting on condition

JNI global references: 6


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x15268f14 (object 0x04ee2840, a java.lang.Integer),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x15267624 (object 0x04ef8920, a java.lang.Integer),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at com.agree.Exam.ThreadRunB.run(DiedsynchronizedTest.java:42)
        - waiting to lock <0x04ee2840> (a java.lang.Integer)
        - locked <0x04ef8920> (a java.lang.Integer)
"Thread-0":
        at com.agree.Exam.ThreadRunA.run(DiedsynchronizedTest.java:21)
        - waiting to lock <0x04ef8920> (a java.lang.Integer)
        - locked <0x04ee2840> (a java.lang.Integer)

Found 1 deadlock.
 
"Thread-1" #9 prio=5 os_prio=0 tid=0x15360400 nid=0x280c waiting for monitor entry [0x159cf000]
 
“Thread-1”:线程名称
 
#9：线程编号
 
prio：线程的优先级别
 
os_prio：系统级别的线程优先级
 
tid：线程id
 
nid:native线程id
 
waiting for monitor entry [0x159cf000]:线程当前状态
 
进程区域的划分
 
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-grOSvspV-1610000415287)(C:\Users\srqnk\AppData\Roaming\Typora\typora-user-images\1596095856121.png)]
 
先级
 
tid：线程id
 
nid:native线程id
 
waiting for monitor entry [0x159cf000]:线程当前状态
 
进程区域的划分
 
[外链图片转存中…(img-grOSvspV-1610000415287)]
 
重量级锁也就是通常说synchronized的对象锁，锁标识位为10，其中指针指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。

使用jstack观察虚拟机栈情况
 
jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照，查看Java线程的调用堆栈的，可以用来分析线程问题（如死锁）。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合.
 
生成线程快照的目的主要是定位线程长时间出现停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些什么事情，或者在等待些什么资源。
 
以检查线程死锁为例：
 
public class Main_Work_2_1 {
    public static void main(String[] args) throws InterruptedException {
        Map<String, String> resource1 = Map.of("name", "resource1");
        Map<String, String> resource2 = Map.of("name", "resource2");

        Thread thread1 = new Thread(() -> runOverride(resource1, resource2), "线程1");
        Thread thread2 = new Thread(() -> runOverride(resource2, resource1), "线程2");

        thread1.start();
        thread2.start();

    }

    /**
     * run方法运行实例，主要是对先获得哪个锁做限制
     * @param first
     * @param second
     */
    public static void runOverride(Map<String, String> first, Map<String, String> second) {
        Thread threadName = Thread.currentThread();
        synchronized (first) {
            System.out.println(threadName + " get " + first.get("name"));

            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            System.out.println(threadName + " waiting get" + second.get("name"));

            synchronized (second) {
                System.out.println(threadName + " get " + second.get("name"));
            }
        }
    }

}
 
运行输出：
 
Thread[线程1,5,main] get resource1
Thread[线程2,5,main] get resource2
Thread[线程2,5,main] waiting getresource1
Thread[线程1,5,main] waiting getresource2
 
代码分析：线程1 通过 synchronized (first)获得resource1的监视器锁，然后通过Thread.sleep(1000);让线程1 休眠 1s；为的是让线程 2得到执行，然后获取到 resource2的监视器锁。线程 1 和线程 2休眠结束了都开始企图请求获取对方的资源，然后这两个线程就会陷入互相等待的状态，这也就产生了死锁。
 
使用jstack进行栈情况分析：
 
首先使用jps获取目标进程，可以看出Main_Work_2的进程pid为10566；
 
jps
 
 
然后查看对应进程栈内容：
 
jstack 10566
 
运行结果部分截图如下：
 
图一可以看出线程1处于BLOCKED状态，- waiting to lock <0x000000008df738d0>表示正在等待锁<0x000000008df738d0>，并且- locked <0x000000008df73878>表示正持有锁<0x000000008df73878>；线程2也处于BLOCKED状态，- waiting to lock <0x000000008df73878>表示正在等待锁<0x000000008df73878>，并且- locked <0x000000008df738d0>表示正持有锁<0x000000008df738d0>。
 
图二可以看出找到一个死锁，并且可以很明显的知道线程1在等待一个锁，该锁已被线程2获取；线程2也在等待一个锁，该锁已被线程1获取。
 
 
 
 
 
如果将死锁代码修改成正常代码后，在进程正常运行时，再一次使用stack查看的话，就会发现运行结果正常了。
 
 
也可以使用一下命令将结果输出到文件当中，方便记录和传阅。
 
jstack pid > jstackOut.txt
 
jstack命令
 
命令格式
 
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@] remote-hostname-or-IP
 
常用参数说明
 
1）options：
 
 
 
executable：Java executable from which the core dump was produced.(可能是产生core dump的java可执行程序)
 
 
core：将被打印信息的core dump文件
 
 
remote-hostname-or-IP：远程debug服务的主机名或ip
 
 
server-id：唯一id,假如一台主机上多个远程debug服务
 
 
2）基本参数：
 
 
 
-F：当’jstack [-l] pid’没有相应的时候强制打印栈信息,如果直接jstack无响应时，用于强制jstack），一般情况不需要使用
 
 
-l：长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表，会使得JVM停顿得长久得多（可能会差很多倍，比如普通的jstack可能几毫秒和一次GC没区别，加了-l 就是近一秒的时间），-l 建议不要用。一般情况不需要使用
 
 
-m：打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧，一般应用排查不需要使用
 
 
-h | -help：打印帮助信息
 
 
3）pid
 
pid 需要被打印配置信息的java进程id,可以用jps查询.
 
线程状态
 
想要通过jstack命令来分析线程的情况的话，首先要知道线程都有哪些状态，下面这些状态是我们使用jstack命令查看线程堆栈信息时可能会看到的线程的几种状态：
 
NEW：未启动的。不会出现在Dump中。
 
RUNNABLE：在虚拟机内执行的。运行中状态，可能里面还能看到locked字样，表明它获得了某把锁。
 
BLOCKED：受阻塞并等待监视器锁，被某个锁(synchronizers)给block住了。
 
WATING：无限期等待另一个线程执行特定操作；等待某个condition或monitor发生，一般停留在park(), wait(), sleep(),join() 等语句里。
 
TIMED_WATING：有时限的等待另一个线程的特定操作；和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。
 
TERMINATED：已退出的。
 
调用修饰
 
表示线程在方法调用时，额外的重要的操作。线程Dump分析的重要信息，修饰上方的方法调用。
 
locked <地址> 目标：使用synchronized申请对象锁成功,监视器的拥有者。
 
waiting to lock <地址> 目标：使用synchronized申请对象锁未成功,在进入区等待。
 
waiting on <地址> 目标：使用synchronized申请对象锁成功后,释放后在等待区等待。
 
parking to wait for <地址> 目标：park是基本的线程阻塞原语，不通过监视器在对象上阻塞。随concurrent包会出现的新的机制，与synchronized体系不同。
 
线程动作
 
线程状态产生的原因
 
runnable: 状态一般为RUNNABLE。
 
in Object.wait(): 等待区等待,状态为WAITING或TIMED_WAITING。
 
waiting for monitor entry: 进入区等待,状态为BLOCKED。
 
waiting on condition: 等待区等待、被park。
 
sleeping: 休眠的线程,调用了Thread.sleep()。