Jstack
jstack命令的语法格式: jstack 。可以用jps查看java进程id。这里要注意的是:
\1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的,不同的 JVM版本, dump信息也有差别。
\2. 在实际运行中,往往一次 dump的信息,还不足以确认问题。建议产生三次 dump信息,如果每次 dump都指向同一个问题,我们才确定问题的典型性。
jstack Dump 日志文件中的线程状态
dump 线程状态
死锁, Deadlock(重点关注)
执行中,Runnable
等待资源, Waiting on condition(重点关注)
等待获取监视器, Waiting on monitor entry(重点关注)
暂停,Suspended
对象等待中,Object.wait() 或 TIMED_WAITING
阻塞, Blocked(重点关注)
停止,Parked
线程状态含义
Deadlock:死锁线程,一般指多个线程调用间,进入相互资源占用,导致一直等待无法释放的情况。
Runnable:一般指该线程正在执行状态中,该线程占用了资源,正在处理某个请求,有可能正在传递SQL到数据库执行,有可能在对某个文件操作,有可能进行数据类型等转换。
Waiting on condition:该状态出现在线程等待某个条件的发生。具体是什么原因,可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写,比如当网络数据没有准备好读时,线程处于这种等待状态,而一旦有数据准备好读之后,线程会重新激活,读取并处理数据。在 Java引入 NewIO之前,对于每个网络连接,都有一个对应的线程来处理网络的读写操作,即使没有可读写的数据,线程仍然阻塞在读写操作上,这样有可能造成资源浪费,而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制,编写的服务器程序的性能和可扩展性都得到提高。
如果发现有大量的线程都在处在 Wait on condition,从线程 stack看, 正等待网络读写,这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙,几 乎消耗了所有的带宽,仍然有大量数据等待网络读 写;另一种情况也可能是网络空闲,但由于路由等问题,导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析,比如 netstat统计单位时间的发送包的数目,如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率,如果系统态的 CPU时间,相对于用户态的 CPU时间比例较高;如果程序运行在 Solaris 10平台上,可以用 dtrace工具看系统调用的情况,如果观察到 read/write的系统调用的次数或者运行时间遥遥领先;这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep,等待 sleep的时间到了时候,将被唤醒。
locked:线程阻塞,是指当前线程执行过程中,所需要的资源长时间等待却一直未能获取到,被容器的线程管理器标识为阻塞状态,可以理解为等待资源超时的线程。
Waiting for monitor entry 和 in Object.wait():Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。
C:\Users\srqnk>jstack 8064
2020-07-30 11:25:22
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode):
"DestroyJavaVM" #10 prio=5 os_prio=0 tid=0x00f5cc00 nid=0x1edc waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"Thread-1" #9 prio=5 os_prio=0 tid=0x15360400 nid=0x280c waiting for monitor entry [0x159cf000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.agree.Exam.ThreadRunB.run(DiedsynchronizedTest.java:42)
- waiting to lock <0x04ee2840> (a java.lang.Integer)
- locked <0x04ef8920> (a java.lang.Integer)
"Thread-0" #8 prio=5 os_prio=0 tid=0x1535fc00 nid=0x3968 waiting for monitor entry [0x1593f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.agree.Exam.ThreadRunA.run(DiedsynchronizedTest.java:21)
- waiting to lock <0x04ef8920> (a java.lang.Integer)
- locked <0x04ee2840> (a java.lang.Integer)
"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x152f2800 nid=0x524 runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x152c4000 nid=0x960 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x15298000 nid=0x2fe4 waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x152c3000 nid=0x1e3c runnable [0x00000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x1527a400 nid=0x2718 in Object.wait() [0x1557f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x04e07ee0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
- locked <0x04e07ee0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x15264400 nid=0x2630 in Object.wait() [0x154ef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x04e05f68> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x04e05f68> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"VM Thread" os_prio=2 tid=0x02c6dc00 nid=0xcb4 runnable
"VM Periodic Task Thread" os_prio=2 tid=0x1533b800 nid=0x5c4 waiting on condition
JNI global references: 6
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x15268f14 (object 0x04ee2840, a java.lang.Integer),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x15267624 (object 0x04ef8920, a java.lang.Integer),
which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
at com.agree.Exam.ThreadRunB.run(DiedsynchronizedTest.java:42)
- waiting to lock <0x04ee2840> (a java.lang.Integer)
- locked <0x04ef8920> (a java.lang.Integer)
"Thread-0":
at com.agree.Exam.ThreadRunA.run(DiedsynchronizedTest.java:21)
- waiting to lock <0x04ef8920> (a java.lang.Integer)
- locked <0x04ee2840> (a java.lang.Integer)
Found 1 deadlock.
"Thread-1" #9 prio=5 os_prio=0 tid=0x15360400 nid=0x280c waiting for monitor entry [0x159cf000]
“Thread-1”:线程名称
#9:线程编号
prio:线程的优先级别
os_prio:系统级别的线程优先级
tid:线程id
nid:native线程id
waiting for monitor entry [0x159cf000]:线程当前状态
进程区域的划分
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-grOSvspV-1610000415287)(C:\Users\srqnk\AppData\Roaming\Typora\typora-user-images\1596095856121.png)]
先级
tid:线程id
nid:native线程id
waiting for monitor entry [0x159cf000]:线程当前状态
进程区域的划分
[外链图片转存中…(img-grOSvspV-1610000415287)]
重量级锁也就是通常说synchronized的对象锁,锁标识位为10,其中指针指向的是monitor对象(也称为管程或监视器锁)的起始地址。每个对象都存在着一个 monitor 与之关联,对象与其 monitor 之间的关系有存在多种实现方式,如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成,但当一个 monitor 被某个线程持有后,它便处于锁定状态。