Java线程诊断
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线程诊断的更多相关文章
- Java 死锁诊断 -- 线程转储
java线程转储 java的线程转储可以被定义为JVM中在某一个给定的时刻运行的所有线程的快照.一个线程转储可能包含一个单独的线程或者多个线程.在多线程环境中,比如J2EE应用服务器,将会有许多线程和 ...
- Linux系统监控命令及如何定位到Java线程
>>PID.TID的区分 uid是user id,即用户id,root用户的uid是0,0为最高权限,gid是group id,用户组id,使用 id 命令可以很简单的通过用户名查看UID ...
- 基于 JVMTI 实现 Java 线程的监控(转)
随着多核 CPU 的日益普及,越来越多的 Java 应用程序使用多线程并行计算来充分发挥整个系统的性能.多线程的使用也给应用程序开发人员带来了巨大的挑战,不正确地使用多线程可能造成线程死锁或资源竞争, ...
- Thread Dump 和Java应用诊断(转)
Thread Dump 和Java应用诊断 Thread Dump是非常有用的诊断Java应用问题的工具,每一个Java虚拟机都有及时生成显示所有线程在某一点状态的thread-dump的能力.虽然各 ...
- Linux系统监控命令及定位Java线程
1.PID.TID的区分 uid是user id,即用户id,root用户的uid是0,0为最高权限,gid是group id,用户组id,使用 id 命令可以很简单的通过用户名查看UID.GID:~ ...
- Java 线程转储 [转]
http://www.oschina.net/translate/java-thread-dump java线程转储 java的线程转储可以被定义为JVM中在某一个给定的时刻运行的所有线程的快照.一个 ...
- Java 线程转储
软件维护是一个枯燥而又有挑战性的工作.只要软件功能符合预期,那么这个工作就是好的.设想一个这样的情景,你的电话半夜也一直在响(这不是一个令人愉快的感受,是吧?)任何软件系统,无论它当初是被设计的多好, ...
- 【Java并发专题之二】Java线程基础
使用线程更好的提高资源利用率,但也会带来上下文切换的消耗,频繁的内核态和用户态的切换消耗,如果代码设计不好,可能弊大于利. 一.线程 进程是分配资源的最小单位,线程是程序执行的最小单位:线程是依附于进 ...
- java应用诊断和在线debug利器bistoury介绍与在K8S环境使用
Bistoury介绍 Bistoury 是去哪儿网开源的一个对应用透明,无侵入的java应用诊断工具,用于提升开发人员的诊断效率和能力,可以让开发人员无需登录机器或修改系统,就可以从日志.内存.线程. ...
- Java 线程与同步的性能优化
本文探讨的主题是,如何挖掘出Java线程和同步设施的最大性能. 1.线程池与ThreadPoolExecutor 1)线程池与ThreadPoolExecutor 线程池的实现可能有所不同,但基本概念 ...
随机推荐
- 记一个深层的bug
1. 业务场景 产品需要每隔几天进行一次组件的更新,在自动化测试中,每隔30s检测一次更新源上的某个文件MD5值是否与本地一致,不一致代表有更新的版本,开始更新. 2. 问题出现 一个再平常不过的繁忙 ...
- 齐博x1客服系统显示客户在哪个页面
如下图所示,要想实现下面的效果,即显示客户给你发消息时,当时处于哪个商品页面.这样方便跟客户针对此商品进行交流. 你的模板如果使用了碎片的话,就可以添加下面的代码index_style/default ...
- 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. ...
- SpringBoot内置工具类,告别瞎写工具类了
不知大家有没有注意到,接手的项目中存在多个重复的工具类,发现其中很多功能,Spring 自带的都有.于是整理了本文,希望能够帮助到大家! 一.断言 断言是一个逻辑判断,用于检查不应该发生的情况 Ass ...
- Arctic 基于 Hive 的流批一体实践
背景 随着大数据业务的发展,基于 Hive 的数仓体系逐渐难以满足日益增长的业务需求,一方面已有很大体量的用户,但是在实时性,功能性上严重缺失:另一方面 Hudi,Iceberg 这类系统在事务性,快 ...
- 九、docker swarm主机编排
一. 什么是Docker Swarm Swarm 是 Docker 公司推出的用来管理 docker 集群的平台,几乎全部用GO语言来完成的开发的,代码开源在https://github.com/do ...
- 蓝桥杯赛前复习C++
C标准库常用函数 memset函数:暴力清空 void *memset(void *str, int c, size_t n) str -- 指向要填充的内存块. c -- 要被设置的值.该值以 in ...
- 扫雷(哈希+bfs)
扫雷 题目描述: 小明最近迷上了一款名为<扫雷>的游戏. 其中有一个关卡的任务如下: 在一个二维平面上放置着 n 个炸雷,第 i 个炸雷 (x\(_i\),y\(_i\),r\(_i\)) ...
- Django系列---开发三 前后端分离
数据交互接口规范REST,全称 Representational State Transfer,意为"表现层状态转化". django的第三方拓展--django-rest-fra ...
- Django的简单使用
Django 基础简介 基础简介 1. 软件框架 一个公司是由公司中的各部部门来组成的,每一个部门拥有特定的职能,部门与部门之间通过相互的配合来完成让公司运转起来. 一个软件框架是由其中各个软件模块组 ...