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&quot;ActiveMQ InactivityMonitor Worker&quot; #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  &lt;0x000000071cf5ea58&gt; (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&quot;ActiveMQ InactivityMonitor Worker&quot; #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  &lt;0x000000071cf5ea58&gt; (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的线程并定位代码

六、参考链接

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

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

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

如果有幸看到这个问题，还请留言，谢谢！

{{userData.name}}已认证

Java性能调优工具——Jstack

一、命令说明

二、参数说明

三、使用示例

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

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

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

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

六、参考链接

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

详解Node.js API系列 Crypto加密模块(2) Hmac

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

{{userData.name}}已认证

一、命令说明

二、参数说明

三、使用示例

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

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

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

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

六、参考链接

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

Related posts:

详解Node.js API系列 Crypto加密模块(2) Hmac

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

Linux的系统调用、网络连接状态、磁盘I/O；可疑行为监控/日志收集、SHELL命令执行流程

java内存溢出分析工具：jmap使用实战

JVM性能优化系列-(2) 垃圾收集器与内存分配策略

JVM垃圾回收与性能调优