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

简介: 示例代码: public class CPULockTest { private static Object lock1 = new Object(); private static Object lock2 = new Object(); public ...

示例代码:

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

 

目录
打赏
0
0
0
0
12
分享
相关文章
【YashanDB知识库】YCM上CPU负载超过实际核数是怎么回事
【YashanDB知识库】YCM上CPU负载超过实际核数是怎么回事
taosd 写入与查询场景下压缩解压及加密解密的 CPU 占用分析
在当今大数据时代,时序数据库的应用越来越广泛,尤其是在物联网、工业监控、金融分析等领域。TDengine 作为一款高性能的时序数据库,凭借独特的存储架构和高效的压缩算法,在存储和查询效率上表现出色。然而,随着数据规模的不断增长,在保证数据安全性和存储效率的同时,如何优化 CPU 的资源占用,成为了一个值得深入讨论的问题。
23 1
|
13天前
|
理解CPU负载与使用率
**CPU使用率与负载简介** - **CPU使用率**:指CPU被占用的时间占总时间的比例,单核为直接比例,多核为各核心平均值。高使用率(如80%-90%)表示CPU繁忙,可能导致系统变慢;低使用率(如10%-20%)则表示系统运行流畅。 - **CPU负载**:指等待CPU处理的任务数量,通常显示1分钟、5分钟和15分钟的平均值。高负载意味着任务排队多,可能造成系统卡顿;正常负载下系统运行顺畅。负载反映任务量,使用率反映实际占用时间,两者可不同步。
45 5
Python GIL(全局解释器锁)机制对多线程性能影响的深度分析
在Python开发中,GIL(全局解释器锁)一直备受关注。本文基于CPython解释器,探讨GIL的技术本质及其对程序性能的影响。GIL确保同一时刻只有一个线程执行代码,以保护内存管理的安全性,但也限制了多线程并行计算的效率。文章分析了GIL的必要性、局限性,并介绍了多进程、异步编程等替代方案。尽管Python 3.13计划移除GIL,但该特性至少要到2028年才会默认禁用,因此理解GIL仍至关重要。
195 16
Python GIL(全局解释器锁)机制对多线程性能影响的深度分析
Redis 新版本引入多线程的利弊分析
【10月更文挑战第16天】Redis 新版本引入多线程是一个具有挑战性和机遇的改变。虽然多线程带来了一些潜在的问题和挑战,但也为 Redis 提供了进一步提升性能和扩展能力的可能性。在实际应用中,我们需要根据具体的需求和场景,综合评估多线程的利弊,谨慎地选择和使用 Redis 的新版本。同时,Redis 开发者也需要不断努力,优化和完善多线程机制,以提供更加稳定、高效和可靠的 Redis 服务。
129 1
我是如何通过火焰图分析让应用CPU占用下降近20%的
分享作者在使用Arthas火焰图工具进行Java应用性能分析和优化的经验。
【YashanDB知识库】YCM上CPU负载超过实际核数是怎么回事
【YashanDB知识库】YCM上CPU负载超过实际核数是怎么回事
|
5月前
线程CPU异常定位分析
【10月更文挑战第3天】 开发过程中会出现一些CPU异常升高的问题,想要定位到具体的位置就需要一系列的分析,记录一些分析手段。
151 0
面试官:单核 CPU 支持 Java 多线程吗?为什么?被问懵了!
本文介绍了多线程环境下的几个关键概念,包括时间片、超线程、上下文切换及其影响因素,以及线程调度的两种方式——抢占式调度和协同式调度。文章还讨论了减少上下文切换次数以提高多线程程序效率的方法,如无锁并发编程、使用CAS算法等,并提出了合理的线程数量配置策略,以平衡CPU利用率和线程切换开销。
面试官:单核 CPU 支持 Java 多线程吗?为什么?被问懵了!
|
3月前
|
核心概念解析:进程与线程的对比分析
在操作系统和计算机编程领域,进程和线程是两个基本而核心的概念。它们是程序执行和资源管理的基础,但它们之间存在显著的差异。本文将深入探讨进程与线程的区别,并分析它们在现代软件开发中的应用和重要性。
121 4

热门文章

最新文章

相关实验场景

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等