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

示例代码:

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是否有差别。

时间: 2024-10-24 18:47:43

从cpu负载到jstack分析线程状态的相关文章

jstack和线程dump分析

一:jstack jstack命令的语法格式: jstack  <pid>.可以用jps查看java进程id.这里要注意的是:1. 不同的 JAVA虚机的线程 DUMP的创建方法和文件格式是不一样的,不同的 JVM版本, dump信息也有差别.本文中,只以 SUN的 hotspot JVM 5.0_06 为例.2. 在实际运行中,往往一次 dump的信息,还不足以确认问题.建议产生三次 dump信息,如果每次 dump都指向同一个问题,我们才确定问题的典型性.  二:线程分析 2.1. JVM

Java内存泄漏分析系列之一:使用jstack定位线程堆栈信息

原文地址:http://www.javatang.com 前一段时间上线的系统升级之后,出现了严重的高CPU的问题,于是开始了一系列的优化处理之中,现在将这个过程做成一个系列的文章. 基本概念 在对Java内存泄漏进行分析的时候,需要对jvm运行期间的内存占用.线程执行等情况进行记录的dump文件,常用的主要有thread dump和heap dump. thread dump 主要记录JVM在某一时刻各个线程执行的情况,以栈的形式显示,是一个文本文件.通过对thread dump文件可以分析出

JVM故障分析系列之四:jstack生成的Thread Dump日志线程状态

JVM故障分析系列之四:jstack生成的Thread Dump日志线程状态 2017年10月25日  Jet Ma  JavaPlatform JVM故障分析系列系列文章 JVM故障分析系列之一:使用jstack定位线程堆栈信息JVM故障分析系列之二:jstack生成的Thread Dump日志结构解析JVM故障分析系列之三:jstat命令的使用及VM Thread分析JVM故障分析系列之四:jstack生成的Thread Dump日志线程状态JVM故障分析系列之五:常见的Thread Dum

jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令

公司内部同事分享的一篇文章 周末看到一个用jstack查看死锁的例子.昨天晚上总结了一下jstack(查看线程).jmap(查看内存)和jstat(性能分析)命令.供大家参考 1.Jstack 1.1   jstack能得到运行java程序的java stack和native stack的信息.可以轻松得知当前线程的运行情况.如下图所示 注:这个和thread dump是同样的结果.但是thread dump是用kill -3 pid命令,还是服务器上面少用kill为妙 1.2   命名行格式

jstack Dump日志文件中的线程状态

jstack Dump 日志文件中的线程状态 dump 文件里,值得关注的线程状态有: 死锁,Deadlock(重点关注)  执行中,Runnable 等待资源,Waiting on condition(重点关注) 等待获取监视器,Waiting on monitor entry(重点关注) 暂停,Suspended 对象等待中,Object.wait() 或 TIMED_WAITING 阻塞,Blocked(重点关注)   停止,Parked 下面我们先从第一个例子开始分析,然后再列出不同线程

CPU使用率和负载,物理CPU个数,核数,线程数

当我们使用top命令查看系统的资源使用情况时会看到 load average,如下图所示.它表示系统在1.5.15分钟的平均工作负载.那么什么是负载(load)呢?它和CPU的利用率又有什么关系呢? load average:系统平均负载是CPU的Load,它所包含的信息不是CPU的使用率状况,而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息.这个数字越小越好. 1. CPU负载和CPU利用率的区别 CPU利用率:显示的是程序在运行期间

linux查看线程状态--jstack

在linux下运行多线程程序,想查看各个线程的运行情况,怎么办? Linux下查看某进程的线程状态: 1.jps或top或ps -ef|grep java,找到需要的进程pid: 2.jstack pid,查看pid的所有线程状态信息: 下面为一个示例:进程6798启动了5个线程,其他两个正在跑,另外三个进入了睡眠状态. [[email protected] topology]# jstack 6798 2015-03-02 09:49:05 Full thread dump Java HotS

Linux 线程占用CPU过高定位分析

今天朋友问我一个Linux程序CPU占用涨停了,该如何分析, CPU占用过高,模拟CPU占用过高的情况 先上一段代码: 1 #include <iostream> 2 #include <thread> 3 #include <vector> 4 5 6 int main(int argc, char **argv) { 7 8 std::vector<std::thread> test_threads; 9 for(int i = 0; i < 9;

Linux下CPU占用率高分析方法

一.可能有线程一直占用CPU资源 1. 先通过 ps 查看进程状态,找出进程的PID(8209). 2.jstack -l 8209 > /usr/local/work/tomcat/8209.stack 导出PID对应的线程信息到文件 3.对导出的线程文件下载本地做分析(可以文本打开) 4. 通过top -H -p 8209 命令查看对应进程是哪个线程占用CPU过高(eg:8308) 5.printf "%x\n" 8308 转换十进制为十六进制 此处为:2074. 6.在导出