码迷,mamicode.com
首页 > 编程语言 > 详细

从cpu负载到jstack分析线程状态

时间:2017-03-14 10:50:34      阅读:314      评论:0      收藏:0      [点我收藏+]

标签:使用情况   dead   exec   intellij   trace   ref   system   sock   evel   

示例代码:

public class CPULockTest {

    private static Object lock1 = new Object();
    private static Object lock2 = new Object();

    public static void main(String[] args) {
        new Thread(()->{
            synchronized (lock1){
                try {
                    System.out.println(Thread.currentThread().getName()+"得到lock1");
                    Thread.sleep(3000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock2){
                    System.out.println(Thread.currentThread().getName()+"得到lock2");
                }
            }
        },"线程1").start();

        new Thread(()->{
            synchronized (lock2){
                try {
                    System.out.println(Thread.currentThread().getName()+"得到lock2");
                    Thread.sleep(3000L);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (lock1){
                    System.out.println(Thread.currentThread().getName()+"得到lock1");
                }
            }
        },"线程2").start();
    }
}

找出pid(进程ID)

top命令

在linux环境下,可以通过top命令查看各个进程的cpu使用情况,默认按cpu使用率排序

jps命令

显示指定系统内所有的HotSpot虚拟机进程。

技术分享

通过进程id看线程情况

linux:通过top -Hp 4548可以查看该进程下各个线程的cpu使用情况,有线程的pid;

mac:

技术分享

jstack查看当前进程的状态

?  ~ jstack 4548       
2017-03-14 09:57:31
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode):
"Attach Listener" #13 daemon prio=9 os_prio=31 tid=0x00007f8c1a222000 nid=0x350f waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"DestroyJavaVM" #12 prio=5 os_prio=31 tid=0x00007f8c1a26c800 nid=0x1703 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"线程2" #11 prio=5 os_prio=31 tid=0x00007f8c1a223000 nid=0x5103 waiting for monitor entry [0x000070000134f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at cn.gov.zcy.fixed.CPULockTest.lambda$main$1(CPULockTest.java:35)
    - waiting to lock <0x0000000795b08d58> (a java.lang.Object)
    - locked <0x0000000795b08d68> (a java.lang.Object)
    at cn.gov.zcy.fixed.CPULockTest$$Lambda$2/859417998.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
"线程1" #10 prio=5 os_prio=31 tid=0x00007f8c19967800 nid=0x4f03 waiting for monitor entry [0x000070000124c000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at cn.gov.zcy.fixed.CPULockTest.lambda$main$0(CPULockTest.java:21)
    - waiting to lock <0x0000000795b08d68> (a java.lang.Object)
    - locked <0x0000000795b08d58> (a java.lang.Object)
    at cn.gov.zcy.fixed.CPULockTest$$Lambda$1/1020391880.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
"Monitor Ctrl-Break" #9 daemon prio=5 os_prio=31 tid=0x00007f8c1a224800 nid=0x4d03 runnable [0x0000700001149000]
   java.lang.Thread.State: RUNNABLE
    at java.net.PlainSocketImpl.socketAccept(Native Method)
    at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
    at java.net.ServerSocket.implAccept(ServerSocket.java:545)
    at java.net.ServerSocket.accept(ServerSocket.java:513)
    at com.intellij.rt.execution.application.AppMain$1.run(AppMain.java:90)
    at java.lang.Thread.run(Thread.java:745)

"Service Thread" #8 daemon prio=9 os_prio=31 tid=0x00007f8c1a029800 nid=0x4903 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"C1 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007f8c1a83f800 nid=0x4703 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007f8c19845000 nid=0x4503 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007f8c1a800800 nid=0x4303 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007f8c1a028000 nid=0x320f runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007f8c1a82d000 nid=0x3003 in Object.wait() [0x000070000092e000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x0000000795588e98> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
    - locked <0x0000000795588e98> (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=31 tid=0x00007f8c19805000 nid=0x2e03 in Object.wait() [0x000070000082b000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x0000000795586b40> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:502)
    at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
    - locked <0x0000000795586b40> (a java.lang.ref.Reference$Lock)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=31 tid=0x00007f8c1a014000 nid=0x2c03 runnable 
"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007f8c1a818800 nid=0x2403 runnable 
"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007f8c1a000800 nid=0x2603 runnable 
"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007f8c19809000 nid=0x2803 runnable 
"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007f8c19809800 nid=0x2a03 runnable 
"VM Periodic Task Thread" os_prio=31 tid=0x00007f8c1b029800 nid=0x4b03 waiting on condition 
JNI global references: 324

Found one Java-level deadlock:
=============================
"线程2":
  waiting to lock monitor 0x00007f8c1a0176b8 (object 0x0000000795b08d58, a java.lang.Object),
  which is held by "线程1"
"线程1":
  waiting to lock monitor 0x00007f8c1a0178c8 (object 0x0000000795b08d68, a java.lang.Object),
  which is held by "线程2"

Java stack information for the threads listed above:
===================================================
"线程2":
    at cn.gov.zcy.fixed.CPULockTest.lambda$main$1(CPULockTest.java:35)
    - waiting to lock <0x0000000795b08d58> (a java.lang.Object)
    - locked <0x0000000795b08d68> (a java.lang.Object)
    at cn.gov.zcy.fixed.CPULockTest$$Lambda$2/859417998.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
"线程1":
    at cn.gov.zcy.fixed.CPULockTest.lambda$main$0(CPULockTest.java:21)
    - waiting to lock <0x0000000795b08d68> (a java.lang.Object)
    - locked <0x0000000795b08d58> (a java.lang.Object)
    at cn.gov.zcy.fixed.CPULockTest$$Lambda$1/1020391880.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.

jstack命令生成的thread dump信息包含了JVM中所有存活的线程,为了分析指定线程,必须找出对应线程的调用栈,应该如何找?

在top命令中,已经获取到了占用cpu资源较高的线程pid,将该pid转成16进制的值,在thread dump中每个线程都有一个nid,找到对应的nid即可;隔段时间再执行一次stack命令获取thread dump,区分两份dump是否有差别。

 

从cpu负载到jstack分析线程状态

标签:使用情况   dead   exec   intellij   trace   ref   system   sock   evel   

原文地址:http://www.cnblogs.com/wade-luffy/p/6547024.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!