Jstack

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 被某个线程持有后，它便处于锁定状态。