1.诊断CPU占用过高

[root@master ~]# nohup java -jar JvmProject.jar & // 有问题的java程序
[1] 1627
[root@master ~]# nohup: ignoring input and appending output to ‘nohup.out’

1.1使用top命令来查看是那个程序占用CPU过高

top - 08:57:03 up 25 min,  1 user,  load average: 0.49, 0.77, 0.58
Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie
%Cpu(s): 99.7 us, 0.3 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 995464 total, 359540 free, 290336 used, 345588 buff/cache
KiB Swap: 1048572 total, 1048572 free, 0 used. 557932 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1710 root 20 0 2241412 28948 11752 S 99.9 2.9 0:09.24 java
1655 root 20 0 0 0 0 S 0.3 0.0 0:00.28 kworker/0:1
1 root 20 0 125484 3892 2584 S 0.0 0.4 0:01.38 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
5 root 20 0 0 0 0 S 0.0 0.0 0:00.07 kworker/u256:0
6 root 20 0 0 0 0 S 0.0 0.0 0:00.06 ksoftirqd/0

1.2使用ps -H -eo pid,tid,%cpu | grep 进程ID(用PS命令进一步定位是哪个线程引起的cpu占用过高)

[root@master ~]# ps -H -eo pid,tid,%cpu | grep 1790
1790 1790 99.5

1.3.jstack 进程ID 查看该进程中的所有java线程信息

​ 通过进程的id与jstack的结果进行匹配,由于linux中进程id是10进制而java中是16进制所以需要使用进制转换,进程1790+10转换成16进制为708 (在虚拟机中不知道什么原因pid+10 = tid)

[root@master ~]# jstack 1790
2023-01-10 09:05:45
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode): "Attach Listener" #12 daemon prio=9 os_prio=0 tid=0x00007f1d64001000 nid=0x72a waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "DestroyJavaVM" #11 prio=5 os_prio=0 tid=0x00007f1d8c009000 nid=0x6ff waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE "thread3" #10 prio=5 os_prio=0 tid=0x00007f1d8c140000 nid=0x70a waiting on condition [0x00007f1d6968c000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.aircoinst.Demo1_6.lambda$main$2(Demo1_6.java:24)
at com.aircoinst.Demo1_6$$Lambda$3/250421012.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748) "thread2" #9 prio=5 os_prio=0 tid=0x00007f1d8c13e000 nid=0x709 waiting on condition [0x00007f1d6978d000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.aircoinst.Demo1_6.lambda$main$1(Demo1_6.java:15)
at com.aircoinst.Demo1_6$$Lambda$2/455659002.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748) "thread1" #8 prio=5 os_prio=0 tid=0x00007f1d8c13c000 nid=0x708 runnable [0x00007f1d6988e000]
java.lang.Thread.State: RUNNABLE
at com.aircoinst.Demo1_6.lambda$main$0(Demo1_6.java:7) # 该处就是CPU占用过高问题所在(问题代码在第七行)
at com.aircoinst.Demo1_6$$Lambda$1/1406718218.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748) "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f1d8c0db800 nid=0x706 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f1d8c0d8800 nid=0x705 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f1d8c0d6800 nid=0x704 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f1d8c0d4800 nid=0x703 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f1d8c0a1800 nid=0x702 in Object.wait() [0x00007f1d7c422000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000f0c08ed0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- locked <0x00000000f0c08ed0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216) "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f1d8c09e800 nid=0x701 in Object.wait() [0x00007f1d7c523000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000f0c06bf8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000000f0c06bf8> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153) "VM Thread" os_prio=0 tid=0x00007f1d8c095000 nid=0x700 runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007f1d8c0de800 nid=0x707 waiting on condition JNI global references: 311

​ 红色框内就是问题代码,所以该问题可以根据线程id找到有问题的线程,进一步定位到问题代码的源码行号,进行问题分析。

2.程序运行很长时间没有结果

[root@master ~]# nohup java -jar JvmProject.jar &
[1] 1901
[root@master ~]# nohup: ignoring input and appending output to ‘nohup.out’
# 该地方没有程序输出,一直为卡死状态
[root@master ~]#

2.1 使用jps命令查询进程信息,进程id为1901

[root@master ~]# jps
1913 Jps
1901 jar

2.2 使用jstack 进程id命令查看所有线程信息

[root@master ~]# jstack 1901
2023-01-10 09:25:28
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.202-b08 mixed mode): "Attach Listener" #11 daemon prio=9 os_prio=0 tid=0x00007fde70001000 nid=0x78d waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE "DestroyJavaVM" #10 prio=5 os_prio=0 tid=0x00007fde9c009000 nid=0x76e waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
....
....
Found one Java-level deadlock: # 产生了死锁
=============================
"Thread-1":
waiting to lock monitor 0x00007fde7c004e28 (object 0x00000000f0c674c0, a com.aircoinst.A),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00007fde7c0062c8 (object 0x00000000f0c68a80, a com.aircoinst.B),
which is held by "Thread-1" Java stack information for the threads listed above:
===================================================
"Thread-1":
at com.aircoinst.Demo1_7.lambda$main$1(Demo1_7.java:35) # 死锁问题代码行
- waiting to lock <0x00000000f0c674c0> (a com.aircoinst.A) # 等待A对象的锁
- locked <0x00000000f0c68a80> (a com.aircoinst.B) # 当前锁住了B对象
at com.aircoinst.Demo1_7$$Lambda$2/295530567.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
"Thread-0":
at com.aircoinst.Demo1_7.lambda$main$0(Demo1_7.java:27) # 死锁问题代码行
- waiting to lock <0x00000000f0c68a80> (a com.aircoinst.B) # 等待B对象的锁
- locked <0x00000000f0c674c0> (a com.aircoinst.A) # 当前锁住了A对象
at com.aircoinst.Demo1_7$$Lambda$1/250421012.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748) Found 1 deadlock.

对比源代码,发现线程1与线程2同时发生了死锁,造成了相A,B对象互等待释放

Java线程诊断的更多相关文章

  1. Java 死锁诊断 -- 线程转储

    java线程转储 java的线程转储可以被定义为JVM中在某一个给定的时刻运行的所有线程的快照.一个线程转储可能包含一个单独的线程或者多个线程.在多线程环境中,比如J2EE应用服务器,将会有许多线程和 ...

  2. Linux系统监控命令及如何定位到Java线程

    >>PID.TID的区分 uid是user id,即用户id,root用户的uid是0,0为最高权限,gid是group id,用户组id,使用 id 命令可以很简单的通过用户名查看UID ...

  3. 基于 JVMTI 实现 Java 线程的监控(转)

    随着多核 CPU 的日益普及,越来越多的 Java 应用程序使用多线程并行计算来充分发挥整个系统的性能.多线程的使用也给应用程序开发人员带来了巨大的挑战,不正确地使用多线程可能造成线程死锁或资源竞争, ...

  4. Thread Dump 和Java应用诊断(转)

    Thread Dump 和Java应用诊断 Thread Dump是非常有用的诊断Java应用问题的工具,每一个Java虚拟机都有及时生成显示所有线程在某一点状态的thread-dump的能力.虽然各 ...

  5. Linux系统监控命令及定位Java线程

    1.PID.TID的区分 uid是user id,即用户id,root用户的uid是0,0为最高权限,gid是group id,用户组id,使用 id 命令可以很简单的通过用户名查看UID.GID:~ ...

  6. Java 线程转储 [转]

    http://www.oschina.net/translate/java-thread-dump java线程转储 java的线程转储可以被定义为JVM中在某一个给定的时刻运行的所有线程的快照.一个 ...

  7. Java 线程转储

    软件维护是一个枯燥而又有挑战性的工作.只要软件功能符合预期,那么这个工作就是好的.设想一个这样的情景,你的电话半夜也一直在响(这不是一个令人愉快的感受,是吧?)任何软件系统,无论它当初是被设计的多好, ...

  8. 【Java并发专题之二】Java线程基础

    使用线程更好的提高资源利用率,但也会带来上下文切换的消耗,频繁的内核态和用户态的切换消耗,如果代码设计不好,可能弊大于利. 一.线程 进程是分配资源的最小单位,线程是程序执行的最小单位:线程是依附于进 ...

  9. java应用诊断和在线debug利器bistoury介绍与在K8S环境使用

    Bistoury介绍 Bistoury 是去哪儿网开源的一个对应用透明,无侵入的java应用诊断工具,用于提升开发人员的诊断效率和能力,可以让开发人员无需登录机器或修改系统,就可以从日志.内存.线程. ...

  10. Java 线程与同步的性能优化

    本文探讨的主题是,如何挖掘出Java线程和同步设施的最大性能. 1.线程池与ThreadPoolExecutor 1)线程池与ThreadPoolExecutor 线程池的实现可能有所不同,但基本概念 ...

随机推荐

  1. 记一个深层的bug

    1. 业务场景 产品需要每隔几天进行一次组件的更新,在自动化测试中,每隔30s检测一次更新源上的某个文件MD5值是否与本地一致,不一致代表有更新的版本,开始更新. 2. 问题出现 一个再平常不过的繁忙 ...

  2. 齐博x1客服系统显示客户在哪个页面

    如下图所示,要想实现下面的效果,即显示客户给你发消息时,当时处于哪个商品页面.这样方便跟客户针对此商品进行交流. 你的模板如果使用了碎片的话,就可以添加下面的代码index_style/default ...

  3. SpringCloud整合分布式事务Seata 1.4.1 支持微服务全局异常拦截

    项目依赖 SpringBoot 2.5.5 SpringCloud 2020.0.4 Alibaba Spring Cloud 2021.1 Mybatis Plus 3.4.0 Seata 1.4. ...

  4. SpringBoot内置工具类,告别瞎写工具类了

    不知大家有没有注意到,接手的项目中存在多个重复的工具类,发现其中很多功能,Spring 自带的都有.于是整理了本文,希望能够帮助到大家! 一.断言 断言是一个逻辑判断,用于检查不应该发生的情况 Ass ...

  5. Arctic 基于 Hive 的流批一体实践

    背景 随着大数据业务的发展,基于 Hive 的数仓体系逐渐难以满足日益增长的业务需求,一方面已有很大体量的用户,但是在实时性,功能性上严重缺失:另一方面 Hudi,Iceberg 这类系统在事务性,快 ...

  6. 九、docker swarm主机编排

    一. 什么是Docker Swarm Swarm 是 Docker 公司推出的用来管理 docker 集群的平台,几乎全部用GO语言来完成的开发的,代码开源在https://github.com/do ...

  7. 蓝桥杯赛前复习C++

    C标准库常用函数 memset函数:暴力清空 void *memset(void *str, int c, size_t n) str -- 指向要填充的内存块. c -- 要被设置的值.该值以 in ...

  8. 扫雷(哈希+bfs)

    扫雷 题目描述: 小明最近迷上了一款名为<扫雷>的游戏. 其中有一个关卡的任务如下: 在一个二维平面上放置着 n 个炸雷,第 i 个炸雷 (x\(_i\),y\(_i\),r\(_i\)) ...

  9. Django系列---开发三 前后端分离

    数据交互接口规范REST,全称 Representational State Transfer,意为"表现层状态转化". django的第三方拓展--django-rest-fra ...

  10. Django的简单使用

    Django 基础简介 基础简介 1. 软件框架 一个公司是由公司中的各部部门来组成的,每一个部门拥有特定的职能,部门与部门之间通过相互的配合来完成让公司运转起来. 一个软件框架是由其中各个软件模块组 ...