jstack排查常见问题

jstack作为jvm分析工具之一，它只能做线程转储堆栈分析；而通常的性能问题，都是要结合jvm内存，gc，网络，IO等诸多信息综合分析，才能得出问题原因。有时只关注线程转储堆栈，而忽略其他，甚至会误导问题线索。

但是不可否认的是，正确分析线程转储堆栈，经验丰富的程序员直接就能把握住大方向上的问题原因。

要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。 线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题
jstack命令的语法格式： jstack  <pid>

jre/bin/jstack

问题分析前述：

在实际运行中，往往一次 dump的信息，还不足以确认问题。建议产生三次 dump信息，如果每次 dump都指向同一个问题，我们才确定问题的典型性。

常见线程栈状态

死锁， Deadlock（重点关注） ：表示有死锁

执行中，Runnable   

等待资源， Waiting on condition（重点关注） 

等待获取监视器， Waiting on monitor entry（重点关注）：
等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析，比如线程正在sleep，网络读写繁忙而等待

暂停，Suspended

对象等待中，Object.wait() 或 TIMED_WAITING

阻塞， Blocked（重点关注）  

停止，Parked

经验之谈

从各种性能低下或者崩溃的java程序分析实践中总结，有以下经验可供参考：

1.如果大量线程在“waiting for monitor entry”，可能是一个全局锁阻塞住了大量线程。

如果短时间内打印的 thread dump 文件反映，随着时间流逝，waiting for monitor entry 的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。
或者是因为并发太高，全局锁的情况下，waiting for monitor entry 的线程也会很多。

2.如果相同的call stack在不同时间出现在同一个线程上（tid）上， 有很大理由相信， 这段代码可能存在较多的循环或者死循环。

如果不同的时间多次dump线程，发现相同的调用栈出现在同一个线程上，那么说明这段时间跑的都是同一段代码，这种情况出现在死循环或者较多循环的代码

如果不同的时间多次dump线程，发现相同的调用栈出现在同一个线程上，那么说明这段时间跑的都是同一段代码，这种情况出现在死循环或者较多循环的代码

3.如果某个相同的call stack经常出现， 我们有80%的以上的理由确定这个代码存在性能问题（读网络的部分除外）。

.

4.如果大量线程在“waiting on condition”，并且在等待网络资源，可能是网络瓶颈的征兆

最佳实践：

如果大量线程在“waiting for monitor entry”，可能是一个全局锁阻塞住了大量线程。
如果某个相同的call stack经常出现， 我们有80%的以上的理由确定这个代码存在性能问题（读网络的部分除外）。

线程及调用栈表现为，大量的线程等待进入Monitor临界区，有且仅有一个线程成功该Monitor拥有者：

大量线程处于以下状态：

"pool-1-thread-190" prio=10 tid=0x00002b853809d800 nid=0xc01 waiting for monitor entry [0x00002b84b85d5000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.log4j.Category.callAppenders(Category.java:204)
- waiting to lock <0x00000007880579e8> (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.info(Category.java:666)
at com.jlpay.commons.rpc.thrift.server.Dispatcher.invoke(Dispatcher.java:38)
at com.jlpay.commons.rpc.thrift.server.RpcAdapterImpl.Invoke(RpcAdapterImpl.java:32)
at com.jlpay.commons.rpc.thrift.server.RpcAdapter$Processor$Invoke.getResult(RpcAdapter.java:175)
at com.jlpay.commons.rpc.thrift.server.RpcAdapter$Processor$Invoke.getResult(RpcAdapter.java:160)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:518)
at org.apache.thrift.server.Invocation.run(Invocation.java:18)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)

观察地址locked<地址xxxx>

四、Case2 web会话未释放导致的服务崩溃

最佳实践：

Dump线程前，先查看分析jvm内存信息

五、Case3 一个load飙高的过程分析

refer to 一个load飙高的过程分析，非常有价值

六、Case4 死锁

jstack -l <pid> 可以检测到死锁：

"Thread-1" #12 prio=5 os_prio=0 tid=0x000000001e9df000 nid=0x3a78 waiting for monitor entry [0x000000001f3cf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at jstack.JStackDeadLock.fun2(JStackDeadLock.java:31)
        - waiting to lock <0x000000076b881790> (a java.lang.Object)
        - locked <0x000000076b8817a0> (a java.lang.Object)
        at jstack.JStackDeadLock$$Lambda$2/2074407503.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - None

"Thread-0" #11 prio=5 os_prio=0 tid=0x000000001e9de800 nid=0x4244 waiting for monitor entry [0x000000001f2ce000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at jstack.JStackDeadLock.fun1(JStackDeadLock.java:21)
        - waiting to lock <0x000000076b8817a0> (a java.lang.Object)
        - locked <0x000000076b881790> (a java.lang.Object)
        at jstack.JStackDeadLock$$Lambda$1/558638686.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
        - None

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x0000000002c3a758 (object 0x000000076b881790, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x000000001e9ed038 (object 0x000000076b8817a0, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at jstack.JStackDeadLock.fun2(JStackDeadLock.java:31)
        - waiting to lock <0x000000076b881790> (a java.lang.Object)
        - locked <0x000000076b8817a0> (a java.lang.Object)
        at jstack.JStackDeadLock$$Lambda$2/2074407503.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)
"Thread-0":
        at jstack.JStackDeadLock.fun1(JStackDeadLock.java:21)
        - waiting to lock <0x000000076b8817a0> (a java.lang.Object)
        - locked <0x000000076b881790> (a java.lang.Object)
        at jstack.JStackDeadLock$$Lambda$1/558638686.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

　　

可以轻易直观分析，两个锁被两个线程相互持有。

七、Case5 CPU占用高

refer to 如何使用jstack分析线程状态

 八。：

1、获取应用的pid
使用ps -ef | grep java查询服务器上的java应用进程信息，找到应用进程及id
2、使用jmap获取dump信息
jmap -dump:format=b,file=/home/app/dump.out 17740
注：/home/app/dump.out表示生成的dump文件的存放地址及文件名，17740表示1中查询到的应用pid
3、分析dump文件
可使用jstack命令分析，也可以使用eclipse memory analyzer工具分析

参考：
Java获取执行进程的dump文件及获取Java stack
java获取内存dump的几种方式