jstack是java虚拟机自带的一种堆栈跟踪工具。
基本介绍
jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。
线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。
命令格式
jstack [ option ] pid
基本参数：
-F 当’jstack [-l] pid’没有响应的时候强制打印栈信息
-l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表.
-m 打印java和native c/c++框架的所有栈信息. -h | -help打印帮助信息
pid 需要被打印配置信息的java进程id,可以用jps工具查询.
案例
说明
- 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的，不同的 JVM版本， dump信息也有差别。
- 在实际运行中，往往一次 dump的信息，还不足以确认问题。建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。
案例1-使用
先以一个小场景简单示范下 jstack 的使用。
场景：Java应用持续占用很高CPU，需要排查一下。
模拟：造个场景简单模拟下，没什么实际意义，仅作演示。我启动了100个线程持续访问 我的博客，博客部署在Ubuntu 16.04上，是一个简单的Spring Boot应用，以jar包直接运行的。
top 命令查下系统运行情况，进程31951占用CPU 80.6%。
top -Hp 31951 以线程模式查看下进程31951的所有线程情况
假设想看下第二个线程31998的情况，31998是操作系统的线程ID，先转成16进制。（再例如：21233用计算器转换为16进制52f1，注意字母是小写）
printf '%x' 31998 #值为7cfe获取该线程的信息(匹配7cf3后取20行差不多)
jstack 31951 | grep 7cfe -A 20其中部分数据如下：
"Tomcat JDBC Pool Cleaner[11483240:1532362388783]" #31 daemon prio=5 os_prio=0 tid=0x0a29dc00 nid=0x7cfe in Object.wait() [0xa2a69000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:552)
- locked <0xaadc5a60> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)注意：nid=0x7cfe中的nid指native id，是OS中线程ID，对应上面31998线程的16进制值7cfe；tid为Java中线程的ID。
案例2-死锁
在多线程程序的编写中，如果不适当的运用同步机制，则有可能造成程序的死锁，经常表现为程序的停顿，或者不再响应用户的请求。比如在下面这个示例中，是个较为典型的死锁情况：
dump结果
1. "Thread-1"prio=5tid=0x00acc490nid=0xe50waitingformonitorentry[0x02d3f000
2. ..0x02d3fd68]
3. atdeadlockthreads.TestThread.run(TestThread.java:31)
4. -waitingtolock<0x22c19f18>(ajava.lang.Object)
5. -locked<0x22c19f20>(ajava.lang.Object)
6. "Thread-0"prio=5tid=0x00accdb0nid=0xdecwaitingformonitorentry[0x02cff000
7. ..0x02cff9e8]
8. atdeadlockthreads.TestThread.run(TestThread.java:31)
9. -waitingtolock<0x22c19f20>(ajava.lang.Object)
10. -locked<0x22c19f18>(ajava.lang.Object)在 JAVA 5中加强了对死锁的检测。线程 Dump中可以直接报告出 Java级别的死锁，如下所示：
dump结果
1. FoundoneJava-leveldeadlock:
2. =============================
3. "Thread-1":
4. waitingtolockmonitor0x0003f334(object0x22c19f18,ajava.lang.Object),
5. whichisheldby"Thread-0"
6. "Thread-0":
7. waitingtolockmonitor0x0003f314(object0x22c19f20,ajava.lang.Object),
8. whichisheldby"Thread-1"[2]生成死锁（deadlock）的源代码
/**
* 简单的应用,供测试JDK自带的jstack使用 本应用会造成deadlock，可能会导致系统崩溃
* 逻辑：一旦两个线程互相等待的局面出现，死锁（deadlock）就发生了
*/
public class EasyJstack extends Thread {
private EasyJstackResource resourceManger;// 资源管理类的私有引用，通过此引用可以通过其相关接口对资源进行读写
private int a, b;// 将要写入资源的数据
public static void main(String[] args) throws Exception {
EasyJstackResource resourceManager = new EasyJstackResource();
EasyJstack stack1 = new EasyJstack(resourceManager, 1, 2);
EasyJstack stack2 = new EasyJstack(resourceManager, 3, 4);
stack1.start();
stack2.start();
}
public EasyJstack(EasyJstackResource resourceManager, int a, int b) {
this.resourceManger = resourceManager;
this.a = a;
this.b = b;
}
public void run() {
while (true) {
this.resourceManger.read();
this.resourceManger.write(this.a, this.b);
}
}
}
public class EasyJstackResource {
/**
* 管理的两个资源，如果有多个线程并发，那么就会死锁
*/
private Resource resourceA = new Resource();
private Resource resourceB = new Resource();
public EasyJstackResource() {
this.resourceA.setValue(0);
this.resourceB.setValue(0);
}
public int read() {
synchronized (this.resourceA) {
System.out.println(Thread.currentThread().getName() + "线程拿到了资源 resourceA的对象锁");
synchronized (resourceB) {
System.out.println(Thread.currentThread().getName() + "线程拿到了资源 resourceB的对象锁");
return this.resourceA.getValue() + this.resourceB.getValue();
}
}
}
public void write(int a, int b) {
synchronized (this.resourceB) {
System.out.println(Thread.currentThread().getName() + "线程拿到了资源 resourceB的对象锁");
synchronized (this.resourceA) {
System.out.println(Thread.currentThread().getName() + "线程拿到了资源 resourceA的对象锁");
this.resourceA.setValue(a);
this.resourceB.setValue(b);
}
}
}
public class Resource {
private int value;// 资源的属性
public int getValue() {
return value;
}
public void setValue(int value) {
this.value = value;
}
}
}用jstack进行分析和结果
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x00000000577c2bc8 (object 0x00000000d7149440, a com.dxz.jstack.EasyJstackResource$Resource),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00000000577c4118 (object 0x00000000d7149428, a com.dxz.jstack.EasyJstackResource$Resource),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at com.dxz.jstack.EasyJstackResource.read(EasyJstackResource.java:36)
- waiting to lock <0x00000000d7149440> (a com.dxz.jstack.EasyJstackResource$Resource)
- locked <0x00000000d7149428> (a com.dxz.jstack.EasyJstackResource$Resource)
at com.dxz.jstack.EasyJstack.run(EasyJstack.java:41)
"Thread-0":
at com.dxz.jstack.EasyJstackResource.write(EasyJstackResource.java:46)
- waiting to lock <0x00000000d7149428> (a com.dxz.jstack.EasyJstackResource$Resource)
- locked <0x00000000d7149440> (a com.dxz.jstack.EasyJstackResource$Resource)
at com.dxz.jstack.EasyJstack.run(EasyJstack.java:42)
Found 1 deadlock.仔细看这一段文字，告诉我们 EasyJstackResource.java:36出了状况。如果出现了这种情况，我们就要从这里开始顺藤摸瓜，解决问题。
=========================================================
jstack用于打印出给定的Java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使用方式只支持以下的这种方式：jstack [-l] pid
如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。
需要注意的问题:
l 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的，不同的 JVM版本， dump信息也有差别。
l 在实际运行中，往往一次 dump的信息，还不足以确认问题。建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。
2、命令格式
$jstack [ option ] pid
$jstack [ option ] executable core
$jstack [ option ] [server-id@]remote-hostname-or-IP参数说明:
pid: java应用程序的进程号,一般可以通过jps来获得;
executable:产生core dump的java可执行程序;
core:打印出的core文件;
remote-hostname-or-ip:远程debug服务器的名称或IP;
server-id: 唯一id,假如一台主机上多个远程debug服务;示例:
$jstack –l 23561
线程分析:
一般情况下，通过jstack输出的线程信息主要包括：jvm自身线程、用户线程等。其中jvm线程会在jvm启动时就会存在。对于用户线程则是在用户访问时才会生成。
l jvm线程：
在线程中，有一些 JVM内部的后台线程，来执行譬如垃圾回收，或者低内存的检测等等任务，这些线程往往在JVM初始化的时候就存在，如下所示：
|
l 用户级别的线程
还有一类线程是用户级别的，它会根据用户请求的不同而发生变化。该类线程的运行情况往往是我们所关注的重点。而且这一部分也是最容易产生死锁的地方。
|
从上述的代码示例中我们可以看到该用户线程的以下几类信息：
Ø 线程的状态：waiting on condition(等待条件发生)
Ø 线程的调用情况；
Ø 线程对资源的锁定情况；
线程的状态分析：
正如我们刚看到的那样，线程的状态是一个重要的指标，它会显示在线程每行结尾的地方。那么线程常见的有哪些状态呢？线程在什么样的情况下会进入这种状态呢？我们能从中发现什么线索？
l Runnable
该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。
l Waiton condition
该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。
如果发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。
另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。
l Waitingfor monitor entry 和 in Object.wait()
在多线程的 JAVA程序中，实现线程之间的同步，就要说说Monitor。Monitor是Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。下面这个图，描述了线程和 Monitor之间关系，以及线程的状态转换图：
从图中可以看出，每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitorentry”，而在 “Wait Set”中等待的线程状态是“in Object.wait()”。
先看 “Entry Set”里面的线程。我们称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像：
synchronized(obj){
.........
}这时有两种可能性：
该 monitor不被其它线程拥有，Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码 。此时线程将处于Runnable状态；
该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。此时dump的信息显示“waiting for monitor entry”。
|
临界区的设置，是为了保证其内部的代码执行的原子性和完整性。但是因为临界区在任何时间只允许线程串行通过，这和我们多线程的程序的初衷是相反的。如果在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在线程 DUMP中发现了这个情况，应该审查源码，改进程序。
现在我们再来看现在线程为什么会进入 “Wait Set”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ， “ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的Monitor，恢复到运行态。在 “Wait Set”中的线程， DUMP中表现为： in Object.wait()，类似于：
|
仔细观察上面的 DUMP信息，你会发现它有以下两行：
² locked <0xef63beb8> (ajava.util.ArrayList)
² waiting on <0xef63beb8> (ajava.util.ArrayList)
这里需要解释一下，为什么先 lock了这个对象，然后又 waiting on同一个对象呢？让我们看看这个线程对应的代码：
synchronized(obj){
.........
obj.wait();
.........
}线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于 locked <0xef63beb8> ）。当执行到 obj.wait(), 线程即放弃了 Monitor的所有权，进入 “wait set”队列（对应于 waiting on<0xef63beb8> ）。
往在你的程序中，会出现多个类似的线程，他们都有相似的 dump也可能是正常的。比如，在程序中有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被notify，当然只有一个线程获得了 lock，继续执行，而其它线程继续等待。
