JVM分析工具——jstack实践

JVM分析工具——jstack实践

一、不是万能的jstack

企业级的Java程序中,java程序出现性能低下甚至直接崩溃时,就不能像解决业务bug那样,从行为表现上来修复问题了。性能问题一般是jvm资源告罄的表现,需要结合jvm的相关信息,程序日志以及程序代码解决问题了。

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

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

二、最佳实践

以下是分析线程转储堆栈的一些有效实践:

  1. 虚拟机执行Full GC时,stop the world 会阻塞其他线程,Dump线程前,应该查看内存使用情况以及GC信息。
  2. 方法调用栈结合阅读代码推理,相互推导印证,往往更能发现问题。
  3. Bug的原因往往不会直接在调用栈上直接体现,一定要注意当前调用之前的调用情况。

如何分析

拿到一段可能有问题的线程转储堆栈,如何入手开始分析?

  1. 首先关注BLOCKED 状态的线程,分析调用栈
  2. 再关注WAITING 状态的线程,分析调用栈
  3. 结合经验看问题

入手总结

Deadlock:表示有死锁
Waiting on condition:等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析,比如线程正在sleep,网络读写繁忙而等待
Blocked:阻塞
Waiting on monitor entry:在等待获取锁

经验之谈

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

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

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

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

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

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

.

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

比如说作为web容器的tomcat,某一时刻其大量线程处于WAITING 状态,线程动作是 waiting on condition,调用修饰有park队列,那么说明线程正在等待网络请求的接入,而这时可以进来的网络请求又少,可能是网络瓶颈的征兆,当然也可能是这个网站压根儿没人访问哈哈。

三、Case1 log4j1造成的性能降低

最佳实践:

如果大量线程在“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)

仅有一个线程进入临界区(注意获得的锁地址与以上等待的锁地址相同)

"pool-1-thread-102" prio=10 tid=0x00002b8538053800 nid=0xba9 runnable [0x00002b84b2f71000]
java.lang.Thread.State: RUNNABLE
at java.text.DateFormat.format(DateFormat.java:336)
at org.apache.log4j.helpers.PatternParser$DatePatternConverter.convert(PatternParser.java:443)
at org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)
at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked <0x0000000788057650> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
- locked <0x00000007880579e8> (a org.apache.log4j.spi.RootLogger)

原因是全局锁的存在导致性能降低,此乃log4j1的缺陷,升级日志实现即可。

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

最佳实践:

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

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

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

六、Case4 死锁

jstack -l 可以检测到死锁:

"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分析线程状态


案例持续加入中...

你可能感兴趣的:(JVM分析工具——jstack实践)