一、命令介绍
jstack是jdk自带的jvm分析工具，用于打印指定 java进程，core文件 或者远程 调试服务 的java线程栈信息，从而分析java程序性能不佳或者崩溃的问题。另外该命令是实验性的，不被支持。
jstack命令非常简单，使用自描述的帮助文档，可以快速掌握其使用方法：
jstack -help
Usage:
jstack [-l] <pid>
(to connect to running process)
jstack -F [-m] [-l] <pid>
(to connect to a hung process)
jstack [-m] [-l] <executable> <core>
(to connect to a core file)
jstack [-m] [-l] [server_id@]<remote server IP or hostname>
(to connect to a remote debug server)
Options:
-F to force a thread dump. Use when jstack <pid> does not respond (process is hung)
-m to print both java and native frames (mixed mode)
-l long listing. Prints additional information about locks
-h or -help to print this help message
如上，jstack命令作用的对象有三种，不同对象命令格式如下：
-
进程: 使用
jstack [-l] <pid>来连接到正在运行的进程，使用jstack -F [-m] [-l] <pid>来连接到挂起的进程。 -
core/executable: core文件是Linux下程序不正常退出产生的文件；executable文件是可产生core dump文件的java可执行程序；使用
jstack [-m] [-l] <executable> <core>命令。 -
远程服务:
jstack [-m] [-l] [server_id@]<remote server IP or hostname>连接远程服务。
命令详情参考： java 8关于jstack命令的介绍
snapshoot 快照
一个活跃的java程序，其虚拟机内的线程也是活跃的，不断新建销毁，在各个线程状态之间转移。jstack命令，其实是对命令执行时刻的虚拟机线程集合做一个快照，包含了当前时刻虚拟机内所有线程方法栈。便于通过线程方法栈的行为，定位程序性能不佳或者崩溃问题。这些行为主要是线程之间的同步，如死锁，死循环，等待外部资源竞争锁的行为。通过分析离线文件或者附着到正在运行的java进程，定位问题。
一窥方法栈
一段线程方法栈信息如下：
"localhost-startStop-1-SendThread(10.0.24.14:2181)" daemon prio=10 tid=0x00002b0ee8b4e000 nid=0x4b37 waiting for monitor entry [0x00002b0ed5162000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:204)
- waiting to lock <0x00000000db301138> (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:305)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1156)
跟普通的java方法调用栈很相似，但是又多了些额外的信息，下面重点介绍这些额外的信息。
二、线程状态
jstack打印出的线程状态与java线程状态很相似，但并不是严格意义上相同。
java线程的状态图大概如下：
java线程状态
- NEW: 实例化Thread类后的线程对象，不可执行。
- RUNNABLE: 调用线程的start()方法后；等待CPU时间片。
- RUNNING: 获得CPU时间片，正在执行。
- WAITING: 线程等待其他线程执行特定操作，等待时间不确定。
- TIMED_WAITING: 线程等待其他线程执行特定操作，等待时间确定。
- BLOCKED: 进入同步方法或者同步代码块，没有获取到锁，进入该状态。
- TERMINATED: 线程执行完毕，或者抛出未处理的异常，线程结束。
实际上，Thread的内部枚举类 java.lang.Thread.State 也对java线程状态做了介绍，其中没有 RUNNING 状态，以上是考虑CPU调度引入的这个状态。
thread states
jstack导出的线程方法栈状态也是以java线程状态为准，不过，jvm中的实际线程状态不包括NEW以及TERMINATED，只包括：
- RUNNABLE
- WAITING
- TIMED_WAITING
- BLOCKED
Monitor机制
操作系统为支持进程/线程间的同步，提供了一些基本的同步原语，其中semaphore信号量 和 mutex互斥量是其中最重要的同步原语。但是使用基础同步原语控制并发时，程序员必须维护繁琐的细节，何时应该加锁，何时应该唤醒进程/线程；为便于开发并发程序，一些高级语言支持了Monitor机制，类似语法糖，操作系统本身不支持Monitor，其实现依赖基础同步原语。
具体到高级语言Java，synchronized ，Object(wait, notify/notifyAll)等元素提供了对Monitor机制的支持。直观的代码体现是 同步方法 或者 同步代码块（虽然java的锁机制也提供线程同步，但锁机制与Monitor机制是不同的）。
下图描述了线程状态转移与Monitor的关系：
thread&monitor
整个monitor分为三个区域，处于不同区域的线程有不同的状态：
- Entry Set(进入区)：线程欲获取锁，获取锁成功，进入拥有者区域，否者在进入区等待锁；锁释放后，重新参与竞争锁。
- The Owner(拥有者)：线程成功获得锁。
- Wait Set(等待区)：由于必要条件不满足，线程通过调用对象的wait方法，释放锁，并进入等待区等待被notify/notifyAll唤醒。
Monitor机制中，有且仅有一个线程可以成为Monitor的拥有者，这是这个线程是 An Active Thread；处于 Entry Set以及Wait Set的线程都是 Waiting Thread。
三、线程转储堆栈分析
一条典型的jstack线程栈格式如下：
"线程名" [daemon] prio= os_prio= tid= nid= 线程动作 [线程栈的起始地址]
java.lang.Thread.State:线程状态 [(进入该状态的原因)]
方法调用栈
[-调用修饰]
Locked ownable synchronizers:
- <地址> (可持有同步器对象)
第一行说明线程相关信息，包括：
- 线程名。
- 是否守护线程，daemon标识，非守护线程没有。
- 线程优先级。
- 线程操作系统优先级。
- 线程id。
- 操作系统映射的线程id，十六进制字符串，使用这个id与实际操作系统线程id关联。
- 线程动作。
- 线程栈的起始地址。
线程动作
需要特别说明的是，线程动作，它提供的额外信息利于定位问题；线程动作包括：
- runnable： 线程可执行，对应的线程状态一般为RUNNABLE, 也有例外对应TIMED_WAITING。
- waiting on condition： 调用park阻塞、等待区等待。
- waiting for monitor entry： 处于Monitor Entry Set，对应的线程状态一般是BLOCKED。
- in Object.wait()： 处于Monitor Wait Set，状态为WAITING或TIMED_WAITING。
- sleeping： 调用了sleep，休眠。
第二行是线程的状态，是java.lang.Thread.State中的一种；后面的括号里是进入该状态的原因（可选）。
方法调用栈紧随其后，重要的同步信息也会被输出。
调用修饰
调用修饰是线程方法调用过程中，重要的同步信息；调用修饰包括：
- locked <地址> (目标)： 使用synchronized成功获得对象锁，即Monitor的拥有者。
- waiting to lock <地址> (目标)： 使用synchronized获取对象锁失败，进入Entry Set等待。
- waiting on <地址> (目标)： 使用synchronized获取对象锁成功后，必要条件不满足，调用object.wait()进入Wait Set等待。
- parking to wait for <地址> (目标)： 调用park。
同步原语park比较特殊，不属于Monitor机制，他是锁机制的基础支持。由Unsafe类的native方法park实现。
最后一行是指定了 -l 选项才会输出的，额外的锁信息。表示当前线程获得的可持有同步器。由此可见Monitor机制(synchronized系列)的得天独厚，线程方法栈对Monitor机制的同步信息进行了详尽的说明。Monitor同步机制下，Locked ownable synchronizers为None。由于锁机制的Lock只是普通的java类，jvm无从得知其详尽的线程同步情况，因此使用锁机制实现的线程同步，出现问题时，不如monitor机制的同步实现，不利于辨识。
三、线程动作&调用修饰实践
分析jstack的线程方法栈，主要就是分析线程之间的同步信息，以及其方法调用栈。以上详细介绍了分析jstack的理论知识，下面从实际代码角度，分析jstack线程方法栈。
首先准备好几个同步方法，用于多线程环境下调用：
public class JStack {
// 锁机制
static Lock lock = new ReentrantLock();
// 锁条件对象
static Condition condition = lock.newCondition();
static boolean first = true;
/**
* Monitor机制下的同步
*/
static void monitorSync() {
synchronized (JStack.class) {
while (true) ;
}
}
/**
* Monitor机制下 条件等待
*
* @throws InterruptedException
*/
static void monitorSyncWait() throws InterruptedException {
synchronized (JStack.class) {
if (first) {
first = false;
while (!first) {
JStack.class.wait();
}
}
while (true) ;
}
}
/**
* lock机制下的同步
*/
static void lockSync() {
lock.lock();
try {
while (true) ;
} finally {
lock.unlock();
}
}
/**
* lock机制下条件等待
*
* @throws InterruptedException
*/
static void lockSyncAwait() throws InterruptedException {
lock.lock();
try {
if (first) {
first = false;
while (!first) {
condition.await();
}
}
while (true) ;
} finally {
lock.unlock();
}
}
}
1） Monitor机制，synchronized竞争锁
多线程synchronized竞争锁：
public static void main(String[] args) {
// Monitor机制，synchronized竞争锁
Thread monitorSync1 = new Thread(JStack::monitorSync);
monitorSync1.setName("SYNC monitor#1");
Thread monitorSync2 = new Thread(JStack::monitorSync);
monitorSync2.setName("SYNC monitor#2");
monitorSync1.start();
monitorSync2.start();
}
"SYNC monitor#2" #12 prio=5 os_prio=0 tid=0x000000001f299800 nid=0x3630 waiting for monitor entry [0x000000001fc7f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at jstack.JStack.monitorSync(JStack.java:27)
- waiting to lock <0x000000076b87f128> (a java.lang.Class for jstack.JStack)
at jstack.JStack$$Lambda$2/1989780873.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
"SYNC monitor#1" #11 prio=5 os_prio=0 tid=0x000000001f299000 nid=0x1854 runnable [0x000000001fb7f000]
java.lang.Thread.State: RUNNABLE
at jstack.JStack.monitorSync(JStack.java:27)
- locked <0x000000076b87f128> (a java.lang.Class for jstack.JStack)
at jstack.JStack$$Lambda$1/2093631819.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
可见，Monitor机制下，使用synchronized竞争锁，
- Monitor拥有者
SYNC monitor#1的调用修饰是 lock，线程动作是runnable，状态是RUNNABLE - 竞争锁失败的线程
SYNC monitor#2的调用修饰是 waiting to lock，地址和目标与拥有者线程相同，线程动作是waiting for monitor entry（在Entry Set等待），状态是BLOCKED（在对象监视器上阻塞）。
2） 锁机制，竞争锁
多线程竞争lock锁:
public static void main(String[] args) {
// 锁机制，竞争锁
Thread lockSync1 = new Thread(JStack::lockSync);
lockSync1.setName("SYNC lock#1");
Thread lockSync2 = new Thread(JStack::lockSync);
lockSync2.setName("SYNC lock#2");
lockSync1.start();
lockSync2.start();
}
"SYNC lock#2" #12 prio=5 os_prio=0 tid=0x000000001f1e8800 nid=0x4d8 waiting on condition [0x000000001fbde000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000076b8876d0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at jstack.JStack.lockSync(JStack.java:52)
at jstack.JStack$$Lambda$2/1989780873.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
"SYNC lock#1" #11 prio=5 os_prio=0 tid=0x000000001f1e8000 nid=0x172c runnable [0x000000001fadf000]
java.lang.Thread.State: RUNNABLE
at jstack.JStack.lockSync(JStack.java:54)
at jstack.JStack$$Lambda$1/2093631819.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- <0x000000076b8876d0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
可见，锁机制下，锁竞争同步原语都是park：
- 锁拥有锁线程
SYNC lock#1获取锁并没有调用修饰，而在Locked ownable synchronizers 指明其拥有的可持有同步器（锁），线程动作是runnable，状态时RUNNABLE。 - 竞争锁失败线程
SYNC lock#2的调用修饰是parking to wait for，地址和对象正是拥有者线程持有的锁，线程动作是waiting on condition，状态是WAITING（parking），不同于Monitor未获得锁处于BLOCKED状态。
3） Monitor机制，条件对象上等待
多线程环境下，在monitor机制的条件对象上等待：
public static void main(String[] args) {
// Monitor机制，条件对象上等待
Thread monitorSyncCon1 = new Thread(() -> {
try {
monitorSyncWait();
} catch (InterruptedException e) {
// suppressed
}
});
monitorSyncCon1.setName("SYNC monitor condition#1");
Thread monitorSyncCon2 = new Thread(() -> {
try {
monitorSyncWait();
} catch (InterruptedException e) {
// suppressed
}
});
monitorSyncCon2.setName("SYNC monitor condition#2");
monitorSyncCon1.start();
monitorSyncCon2.start();
}
"SYNC monitor condition#2" #12 prio=5 os_prio=0 tid=0x000000001ed0b000 nid=0x31f8 runnable [0x000000001f6ff000]
java.lang.Thread.State: RUNNABLE
at jstack.JStack.monitorSyncWait(JStack.java:44)
- locked <0x000000076b87f348> (a java.lang.Class for jstack.JStack)
at jstack.JStack.lambda$main$1(JStack.java:110)
at jstack.JStack$$Lambda$2/1989780873.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
"SYNC monitor condition#1" #11 prio=5 os_prio=0 tid=0x000000001ed0a000 nid=0x30d0 in Object.wait() [0x000000001f5fe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x000000076b87f348> (a java.lang.Class for jstack.JStack)
at java.lang.Object.wait(Object.java:502)
at jstack.JStack.monitorSyncWait(JStack.java:41)
- locked <0x000000076b87f348> (a java.lang.Class for jstack.JStack)
at jstack.JStack.lambda$main$0(JStack.java:102)
at jstack.JStack$$Lambda$1/2093631819.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
可见，Monitor机制下，在条件对象上等待：
- 在条件对象上等待的线程
SYNC monitor condition#1, 首先locked <0x000000076b87f348>获得锁成为拥有者，接着主动调用wait方法，waiting on <0x000000076b87f348>后释放锁，在条件对象上等待，进入Wait Set，线程动作是in Object.wait()，状态是WAITING（在对象监视器上等待）。 - 此时成为拥有者的线程
SYNC monitor condition#2，在线程SYNC monitor condition#1主动放弃锁后locked <0x000000076b87f348>获得同一个锁，线程动作是runnable，线程状态是RUNNABLE。
4） Lock机制，条件对象上等待
多线程环境下，竞争lock对象的条件对象：
public static void main(String[] args) {
// Lock机制，条件对象上等待
Thread lockSyncCon1 = new Thread(() -> {
try {
lockSyncAwait();
} catch (InterruptedException e) {
// suppressed
}
});
lockSyncCon1.setName("SYNC lock condition#1");
Thread lockSyncCon2 = new Thread(() -> {
try {
lockSyncAwait();
} catch (InterruptedException e) {
// suppressed
}
});
lockSyncCon2.setName("SYNC monitor condition#2");
lockSyncCon1.start();
lockSyncCon2.start();
}
"SYNC monitor condition#2" #12 prio=5 os_prio=0 tid=0x000000001f1aa800 nid=0x135c waiting on condition [0x000000001fb9e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000076b8894f8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at jstack.JStack.lockSyncAwait(JStack.java:71)
at jstack.JStack.lambda$main$1(JStack.java:131)
at jstack.JStack$$Lambda$2/1989780873.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
"SYNC lock condition#1" #11 prio=5 os_prio=0 tid=0x000000001f1aa000 nid=0x330c runnable [0x000000001fa9f000]
java.lang.Thread.State: RUNNABLE
at jstack.JStack.lockSyncAwait(JStack.java:74)
at jstack.JStack.lambda$main$0(JStack.java:123)
at jstack.JStack$$Lambda$1/2093631819.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- <0x000000076b887af0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
可见，在lock条件对象上等待：
- 一开始获得锁的线程
SYNC monitor condition#2，后来放弃锁在锁的条件对象上等待，方法调用栈中并没有提现这一个过程，只是在最后说明，该线程parking to wait for <0x000000076b8894f8>，线程动作是waiting on condition，状态是WAITING （parking） - 由于线程
SYNC monitor condition#2主动释放锁而获得锁的线程SYNC lock condition#1，Locked ownable synchronizers指示它获得一个锁，处于RUNNABLE状态。
以上，wait或者await方法加上一个超时时间，WAITING状态变为TIMED_WAITING状态
4） sleep
try {
Thread.sleep(50_000);
} catch (InterruptedException e) {
// suppressed
}
"main" #1 prio=5 os_prio=0 tid=0x00000000036e2800 nid=0x2aa8 waiting on condition [0x00000000035df000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at jstack.JStack.main(JStack.java:141)
Locked ownable synchronizers:
- None
REFER TO
[1] linux：core文件的产生和调试
[2] Java 中的 Monitor 机制
