一、命令介绍

jstack是jdk自带的jvm分析工具，用于打印指定 java进程，core文件 或者远程 调试服务 的java线程栈信息，从而分析java程序性能不佳或者崩溃的问题。另外该命令是实验性的，不被支持。

jstack命令非常简单，使用自描述的帮助文档，可以快速掌握其使用方法：

jstack -help

Usage:

jstack [-l]

(to connect to running process)

jstack -F [-m] [-l]

(to connect to a hung process)

jstack [-m] [-l]

(to connect to a core file)

jstack [-m] [-l] [server_id@]

(to connect to a remote debug server)

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

-h or -help to print this help message

如上，jstack命令作用的对象有三种，不同对象命令格式如下：

进程: 使用jstack [-l] 来连接到正在运行的进程，使用 jstack -F [-m] [-l] 来连接到挂起的进程。

core/executable: core文件是Linux下程序不正常退出产生的文件；executable文件是可产生core dump文件的java可执行程序；使用jstack [-m] [-l] 命令。

远程服务: jstack [-m] [-l] [server_id@]连接远程服务。

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