性能监控(8)-导出JVM的线程堆栈信息

jstack用于导出jvm的线程堆栈信息,可以分析线程是否有死锁，以及线程的状态。

可以使用

top -Hp pid 查询出进程内线程的资源占用率

性能监控(8)-导出JVM的线程堆栈信息|jstack，多线程-翰林小院 第1张

将pid转为16进制(printf “%x\n” 2290)之后就是与jstack 导出的信息的nid相对应。

基本语法为

性能监控(8)-导出JVM的线程堆栈信息|jstack，多线程-翰林小院 第2张

Jstack –l<pid>用于打印附加信息。

 

将线程堆栈信息保存至指定文件

Jstack –l <pid> > /opt/pid

打印的线程堆栈信息为

性能监控(8)-导出JVM的线程堆栈信息|jstack，多线程-翰林小院 第3张

其中

线程的状态

1，线程状态为“waiting for monitor entry”：
意味着它 在等待进入一个临界区 ，所以它在”Entry Set“队列中等待。
此时线程状态一般都是 Blocked：
  • java.lang.Thread.State: BLOCKED (on object monitor)
2，线程状态为“waiting on condition”：
说明它在等待另一个条件的发生，来把自己唤醒，或者干脆它是调用了 sleep(N)。
此时线程状态大致为以下几种：
  • java.lang.Thread.State: WAITING (parking)：一直等那个条件发生；
  • java.lang.Thread.State: TIMED_WAITING (parking或sleeping)：定时的，那个条件不到来，也将定时唤醒自己。
3，如果大量线程在“waiting for monitor entry”：
可能是一个全局锁阻塞住了大量线程。
如果短时间内打印的 thread dump 文件反映，随着时间流逝，waiting for monitor entry 的线程越来越多，没有减少的趋势，可能意味着某些线程在临界区里呆的时间太长了，以至于越来越多新线程迟迟无法进入临界区。
4，如果大量线程在“waiting on condition”：
可能是它们又跑去获取第三方资源，尤其是第三方网络资源，迟迟获取不到Response，导致大量线程进入等待状态。
所以如果你发现有大量的线程都处在 Wait on condition，从线程堆栈看，正等待网络读写，这可能是一个网络瓶颈的征兆，因为网络阻塞导致线程无法执行。
线程状态为“in Object.wait()”：
说明它获得了监视器之后，又调用了 java.lang.Object.wait() 方法。
每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。
当线程获得了 Monitor，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。
此时线程状态大致为以下几种：
  • java.lang.Thread.State: TIMED_WAITING (on object monitor)；
  • java.lang.Thread.State: WAITING (on object monitor)；
一般都是RMI相关线程（RMI RenewClean、 GC Daemon、RMI Reaper），GC线程（Finalizer），引用对象垃圾回收线程（Reference Handler）等系统线程处于这种状态。

 

在linux中线程信息可以通过以下命令查找

主要关心如下两个状态

  • BLOCKED 线程在等待monitor锁(synchronized，lock关键字)
  • WAITING 线程在无限等待唤醒 notify

举个MQ影响HTTP连接的实例，以下为jstack返回的信息：

  1. controller.TaskPublicController.batch连接被BLOCKED，

RabbitMqSender.SendEbs 调用MQ.ChannelN.basicPublish推送消息，锁住三个资源，它等待其他线程释放0x000000008391a758锁。

 

  1. 查看0x000000008391a738被谁锁住，搜索0x000000008391a738，发现被ChannelN.basicAck(ChannelN.java:1138)锁住，此线程正在接收MQ的消息并ack，他们使用了同一个Socket中的outputstream，所以并发会有问题。

实例2

等待另一个条件发生来将自己唤醒：

1）“TIMED_WAITING (parking)”中的 timed_waiting 指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。
2）“waiting on condition”需要与堆栈中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)” 结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。其次，SynchronousQueue 并不是一个队列，只是线程之间移交信息的机制，当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。
©版权声明：本文为【翰林小院】（huhanlin.com）原创文章，转载时请注明出处！

发布在

发表评论

电子邮件地址不会被公开。