Java性能调优工具——Jstack

释放双眼,带上耳机,听听看~!

一、命令说明

Jstack是Jdk自带的线程跟踪工具,用于打印指定Java进程的线程堆栈信息。

二、参数说明


1
2
3
1jstack -l [pid]
2
3

注意:windows环境只支持这么一个参数

三、使用示例

jstack -l 5524 > c:\users\Administrator\Desktop\jstack.txt


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
12018-09-14 12:59:46
2Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode):
3
4"ActiveMQ InactivityMonitor Worker" #528 daemon prio=5 os_prio=0 tid=0x000000001ce03800 nid=0x1bc8 waiting on condition [0x000000003dadf000]
5   java.lang.Thread.State: TIMED_WAITING (parking)
6   at sun.misc.Unsafe.park(Native Method)
7   - parking to wait for  <0x000000071cf5ea58> (a java.util.concurrent.SynchronousQueue$TransferStack)
8   at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
9   at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
10  at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
11  at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
12  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
13  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
14  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
15  at java.lang.Thread.run(Thread.java:745)
16
17   Locked ownable synchronizers:
18  - None
19
20"ActiveMQ InactivityMonitor Worker" #527 daemon prio=5 os_prio=0 tid=0x000000001ce05800 nid=0x22c8 waiting on condition [0x000000003f56e000]
21   java.lang.Thread.State: TIMED_WAITING (parking)
22  at sun.misc.Unsafe.park(Native Method)
23  - parking to wait for  <0x000000071cf5ea58> (a java.util.concurrent.SynchronousQueue$TransferStack)
24  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
25  at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
26  at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
27  at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
28  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)
29  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
30  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
31  at java.lang.Thread.run(Thread.java:745)
32
33   Locked ownable synchronizers:
34  - None
35.........
36
37

以下信息摘自:java命令–jstack 工具

线程状态
想要通过jstack命令来分析线程的情况的话,首先要知道线程都有哪些状态,下面这些状态是我们使用jstack命令查看线程堆栈信息时可能会看到的线程的几种状态:

NEW:未启动的。不会出现在Dump中。

RUNNABLE:在虚拟机内执行的。运行中状态,可能里面还能看到locked字样,表明它获得了某把锁。

BLOCKED:受阻塞并等待监视器锁。被某个锁(synchronizers)給block住了。

WATING:无限期等待另一个线程执行特定操作。等待某个condition或monitor发生,一般停留在park(), wait(), sleep(),join() 等语句里。

TIMED_WATING:有时限的等待另一个线程的特定操作。和WAITING的区别是wait() 等语句加上了时间限制 wait(timeout)。

TERMINATED:已退出的。

Monitor
在多线程的 JAVA程序中,实现线程之间的同步,就要说说 Monitor。 Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。下 面这个图,描述了线程和 Monitor之间关系,以 及线程的状态转换图:
Java性能调优工具——Jstack

进入区(Entrt Set):表示线程通过synchronized要求获取对象的锁。如果对象未被锁住,则迚入拥有者;否则则在进入区等待。一旦对象锁被其他线程释放,立即参与竞争。

拥有者(The Owner):表示某一线程成功竞争到对象锁。

等待区(Wait Set) :表示线程通过对象的wait方法,释放对象的锁,并在等待区等待被唤醒。

从图中可以看出,一个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程都是 “Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”,而在“Wait Set”中等待的线程状态是 “in Object.wait()”。 先看 “Entry Set”里面的线程。我们称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时,它就进入了 “Entry Set”队列。对应的 code就像:


1
2
3
4
5
6
1synchronized(obj) {
2.........
3
4}
5
6

调用修饰
表示线程在方法调用时,额外的重要的操作。线程Dump分析的重要信息。修饰上方的方法调用。

locked <地址> 目标:使用synchronized申请对象锁成功,监视器的拥有者。

waiting to lock <地址> 目标:使用synchronized申请对象锁未成功,在迚入区等待。

waiting on <地址> 目标:使用synchronized申请对象锁成功后,释放锁幵在等待区等待。

parking to wait for <地址> 目标 :需与堆栈中的"parking to wait for (atjava.util.concurrent.SynchronousQueue$TransferStack)"结合来看。first–>此线程是在等待某个条件的发生,来把自己唤醒,second–>SynchronousQueue不是一个队列,其是线程之间移交信息的机制,当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务,因此这就是本线程在等待的条件。

locked


1
2
3
4
5
6
7
1at oracle.jdbc.driver.PhysicalConnection.prepareStatement
2- locked &lt;0x00002aab63bf7f58&gt; (a oracle.jdbc.driver.T4CConnection)
3at oracle.jdbc.driver.PhysicalConnection.prepareStatement
4- locked &lt;0x00002aab63bf7f58&gt; (a oracle.jdbc.driver.T4CConnection)
5at com.jiuqi.dna.core.internal.db.datasource.PooledConnection.prepareStatement
6
7

通过synchronized关键字,成功获取到了对象的锁,成为监视器的拥有者,在临界区内操作。对象锁是可以线程重入的。

waiting to lock


1
2
3
4
5
6
7
1at com.jiuqi.dna.core.impl.CacheHolder.isVisibleIn(CacheHolder.java:165)
2- waiting to lock &lt;0x0000000097ba9aa8&gt; (a CacheHolder)
3at com.jiuqi.dna.core.impl.CacheGroup$Index.findHolder
4at com.jiuqi.dna.core.impl.ContextImpl.find
5at com.jiuqi.dna.bap.basedata.common.util.BaseDataCenter.findInfo
6
7

通过synchronized关键字,没有获取到了对象的锁,线程在监视器的进入区等待。在调用栈顶出现,线程状态为Blocked。

waiting on


1
2
3
4
5
6
7
1at java.lang.Object.wait(Native Method)
2- waiting on &lt;0x00000000da2defb0&gt; (a WorkingThread)
3at com.jiuqi.dna.core.impl.WorkingManager.getWorkToDo
4- locked &lt;0x00000000da2defb0&gt; (a WorkingThread)
5at com.jiuqi.dna.core.impl.WorkingThread.run
6
7

通过synchronized关键字,成功获取到了对象的锁后,调用了wait方法,进入对象的等待区等待。在调用栈顶出现,线程状态为WAITING或TIMED_WATING。

parking to wait for

park是基本的线程阻塞原语,不通过监视器在对象上阻塞。随concurrent包会出现的新的机制,不synchronized体系不同。

线程动作
线程状态产生的原因

runnable:状态一般为RUNNABLE。
in Object.wait():等待区等待,状态为WAITING或TIMED_WAITING。
waiting for monitor entry:进入区等待,状态为BLOCKED。
waiting on condition:等待区等待、被park。
sleeping:休眠的线程,调用了Thread.sleep()。

Wait on condition 该状态出现在线程等待某个条件的发生。具体是什么原因,可以结合 stacktrace来分析。 最常见的情况就是线程处于sleep状态,等待被唤醒。 常见的情况还有等待网络IO:在java引入nio之前,对于每个网络连接,都有一个对应的线程来处理网络的读写操作,即使没有可读写的数据,线程仍然阻塞在读写操作上,这样有可能造成资源浪费,而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制,编写的服务器程序的性能和可扩展性都得到提高。 正等待网络读写,这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙,几 乎消耗了所有的带宽,仍然有大量数据等待网络读 写;另一种情况也可能是网络空闲,但由于路由等问题,导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析,比如 netstat统计单位时间的发送包的数目,如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率,如果系统态的 CPU时间,相对于用户态的 CPU时间比例较高;如果程序运行在 Solaris 10平台上,可以用 dtrace工具看系统调用的情况,如果观察到 read/write的系统调用的次数或者运行时间遥遥领先;这些都指向由于网络带宽所限导致的网络瓶颈。(来自http://www.blogjava.net/jzone/articles/303979.html)


四、Windows上如何查看耗CPU最高的线程

使用windows工具ProcessExplorer来获取对应的线程信息,下面这个帖子讲解的实在是太详细了,请需要的同学移步下面链接

windows下揪出java程序占用cpu很高的线程 并找到问题代码 死循环线程代码

五、Linux上如何查看耗CPU最高的线程

这个由于不想安装Linux虚拟机整环境了,请需要的同学直接异步下面链接

JVM调优之jstack找出最耗cpu的线程并定位代码

六、参考链接

  1. java命令–jstack 工具
  2. JVM调优之jstack找出最耗cpu的线程并定位代码
  3. windows下揪出java程序占用cpu很高的线程 并找到问题代码 死循环线程代码

七、关于JDK和JRE的一个疑惑

1 . 为什么运行环境使用JRE,而不是直接使用JDK?
2 . 如果系统有JVM监控相关的需求的话,是否可以考虑直接JDK?

如果有幸看到这个问题,还请留言,谢谢!

给TA打赏
共{{data.count}}人
人已打赏
安全技术

bootstrap栅格系统自定义列

2021-12-21 16:36:11

安全技术

从零搭建自己的SpringBoot后台框架(二十三)

2022-1-12 12:36:11

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索