Jstack 监控

jstack 监控

首选：找到需要监控的java进程

打印进程的所有栈快照（简单粗暴）

jstack [pid] > test.txt将内容写入到文件中方便查询

找到最高CPU使用的线程

1. 通过pid找到，CPU使用率最高的线程
   top -Hp [pid]

2. 找到线程id后，转为16进制

   printf "%x\n" [id]

3. 然后jstack [pid] | grep [id]，可以查看最高CPU使用的线程

jstack 输出的内容结构

"thread-ReportThreadPdf" #49 daemon prio=5 os_prio=0 tid=0x00007feb4632c800 nid=0x3d25b waiting on condition [0x00007fec897fa000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at java.lang.Thread.sleep(Thread.java:340)
	at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
	at com.njmind.qc.report.utils.ReportThreadPdf.run(ReportThreadPdf.java:67)
	at java.lang.Thread.run(Thread.java:748)

第一部分

|-----线程名------| |-线程建立次序-| |是否守护进程| |---线程优先级---| |-------线程 id-------| |-所映射的linux轻量级进程id-| |-------------线程动做--------------|
"thread-ReportThreadPdf" #49 daemon prio=5 os_prio=0 tid=0x00007feb4632c800 nid=0x3d25b waiting on condition [0x00007fec897fa000]

第二部分

线程当前的状态
java.lang.Thread.State: TIMED_WAITING (sleeping)

第三部份

主要记录了线程的调用栈;可用于排查线程死锁...等等;
	at java.lang.Thread.sleep(Native Method)
	at java.lang.Thread.sleep(Thread.java:340)
	at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:386)
	at com.njmind.qc.report.utils.ReportThreadPdf.run(ReportThreadPdf.java:67)
	at java.lang.Thread.run(Thread.java:748)

线程的动做

1. runnable, 表示线程在参与 cpu 资源的竞争, 可能在被调度运行也可能在就绪等待;
2. sleeping, 表示调用了 Thread.sleep(), 线程进入休眠;
3. waiting for monitor entry [0x...], 表示线程在试图获取内置锁, 进入了等待区 Entry Set, 方括号内的地址表示线程等待的资源地址;
4. in Object.wait() [0x...], 表示线程调用了 object.wait(), 放弃了内置锁, 进入了等待区 Wait Set, 等待被唤醒, 方括号内的地址表示线程放弃的资源地址;
5. waiting on condition [0x...], 表示线程被阻塞原语所阻塞, 方括号内的地址表示线程等待的资源地址; 这种和 jvm 的内置锁体系没有关系, 它是 jdk5 以后的 java.util.concurrent 包下的锁机制;

线程的状态

1. RUNNABLE, 这种通常与线程动做 runnable 一块儿出现;
2. BLOCKED (on object monitor), 这种通常与线程动做 waiting for monitor entry 一块儿出现, 不过在其线程调用栈最末端并无一个固定的方法, 由于 synchronized 关键字能够修饰各类方法或者同步块;
3. WAITING (on object monitor) 或者 TIMED_WAITING (on object monitor), 这种通常与线程动做 in Object.wait() [0x...] 一块儿出现, 而且线程调用栈的最末端调用方法为 at java.lang.Object.wait(Native Method), 以表示 object.wait() 方法的调用;
   另外, WAITING 与 TIMED_WAITING 的区别在因而否设置了超时中断, 即 wait(long timeout) 与 wait() 的区别;
4. WAITING (parking) 或者 TIMED_WAITING (parking), 这种通常与线程动做 waiting on condition [0x...] 一块儿出现, 而且线程调用栈的最末端调用方法通常为 at sun.misc.Unsafe.park(Native Method);
   Unsafe.park 使用的是线程阻塞原语, 主要在 java.util.concurrent.locks.AbstractQueuedSynchronizer 类中被使用到, 不少基于 AQS 构建的同步工具, 如 ReentrantLock, Condition, CountDownLatch, Semaphore 等都会诱发线程进入该状态;
   另外, WAITING 与 TIMED_WAITING 的区别与第三点中提到的缘由一致;

线程的重要调用修饰

1. locked <0x...>, 表示其成功获取了内置锁, 成为了 owner;
2. parking to wait for <0x...>, 表示其被阻塞原语所阻塞, 一般与线程动做 waiting on condition 一块儿出现;
3. waiting to lock <0x...>, 表示其在 Entry Set 中等待某个内置锁, 一般与线程动做 waiting for monitor entry 一块儿出现;
4. waiting on <0x...>, 表示其在 Wait Set 中等待被唤醒, 一般与线程动做 in Object.wait() [0x...] 一块儿出现;
   另外, waiting on 调用修饰每每与 locked 调用修饰一同出现,

死锁检测的展现

在 jdk5 以前, Doug Lea 大神尚未发布 java.util.concurrent 包, 这个时候说起的锁, 就仅限于 jvm 监视器内置锁; 此时若是进程内有死锁发生, jstack 将会把死锁检测信息打印出来:

Found one Java-level deadlock:
=============================
"Thread-xxx":
  waiting to lock monitor 0x00007f0134003ae8 (object 0x00000007d6aa2c98, a java.lang.Object),
  which is held by "Thread-yyy"
"Thread-yyy":
  waiting to lock monitor 0x00007f0134006168 (object 0x00000007d6aa2ca8, a java.lang.Object),
  which is held by "Thread-xxx"

Java stack information for the threads listed above:
===================================================
"Thread-xxx":
    ...
"Thread-yyy":
    ...
Found 1 deadlock.