当前位置：首页 > news >正文

Java进程CPU高负载排查

news 2026/2/11 0:36:44

Java进程CPU高负载排查步骤_java进程cpu使用率高排查_YouluBank的博客-CSDN博客
【问题定位】使用arthas定位CPU高的问题_arthas cpu高_秋装什么的博客-CSDN博客

CPU飙升可能原因

CPU 上下文切换过多。
1. 对于 CPU 来说，同一时刻下每个 CPU 核心只能运行-个线程，如果有多个线程要执行，CPU 只能通过上下文切换的方式来执行不同的线程。
2. 上下文切换需要做两个事情：保存运行线程的执行状态；让处于等待中的线程执行
3. 这两个过程需要 CPU 执行内核相关指令实现状态保存，如果较多的上下文切换会占据大量 CPU 资源，从而使得 cpu 无法去执行用户进程中的指令，导致响应速度下降。
在 Java 中，文件1O、网络 1O、锁等待、线程阻塞等操作都会造成线程阻塞从而触发上下文切换
CPU 资源过度消耗，也就是在程序中创建了大量的线程，或者有线程一直占用CPU 资源无法被释放，比如死循环!
CPU 利用率过高之后，导致应用中的线程无法获得 CPU 的调度，从而影响程序的执行效率!

使用命令查找

采用top命令定位进程

登录服务器，执行top命令，查看CPU占用情况，找到进程的pid

很容易发现，PID为29706的java进程的CPU飙升到700%多，且一直降不下来，很显然出现了问题。

使用top -Hp命令定位线程

使用 top -Hp 命令（为Java进程的id号）查看该Java进程内所有线程的资源占用情况

top -Hp 29706

很容易发现，多个线程的CPU占用达到了90%多。我们挑选线程号为30309的线程继续分析。

使用jstack命令定位代码

线程号转换为16进制

printf “%x\n” 命令（tid指线程的id号）将以上10进制的线程号转换为16进制：

printf "%x\n"  30309

转换后的结果分别为7665，由于导出的线程快照中线程的nid是16进制的，而16进制以0x开头，所以对应的16进制的线程号nid为0x7665

采用jstack命令导出线程快照

通过使用dk自带命令jstack获取该java进程的线程快照并输入到文件中： jstack -l > ./jstack_result.txt 命令（为Java进程的id号）来获取线程快照结果并输入到指定文件。

jstack -l 29706 > ./jstack_result.txt

根据线程号定位具体代码

在jstack_result.txt 文件中根据线程好nid搜索对应的线程描述

cat jstack_result.txt |grep -A 100  7665

根据搜索结果，判断应该是ImageConverter.run()方法中的代码出现问题
也可以直接采用jstack |grep -A 200 来定位具体代码

jstack 29706 |grep -A 200 7665

"System Clock" #28 daemon prio=5 os_prio=0 tid=0x00007efc19e8e800 nid=0xae24 waiting on condition [0x00007efbe0d91000]java.lang.Thread.State: TIMED_WAITING (sleeping)at java.lang.Thread.sleep(Native Method)at java.lang.Thread.sleep(Thread.java:340)at java.util.concurrentC.TimeUnit.sleep(TimeUnit.java:386)at com.*.order.Controller.OrderController.detail(OrderController.java:37) //业务代码阻塞点

使用工具查找

使用arthas

下载arthas

curl -O https://arthas.aliyun.com/arthas-boot.jar

1
启动arthas

java -jar arthas-boot.jar

选择3，进行监听我们的应用程序。

模拟CPU高的场景

    @GetMapping("/cpu")public void cpu() {ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(2, 5, 1000, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(100));threadPoolExecutor.execute(new Runnable() {public void run() {while (true) {log.info(System.currentTimeMillis() + "");}}});}

dashboard

thread -n {number}

按照CPU使用率排序，并展示前n个线程

thread [pid]

展示指定线程的线程栈

模拟查看方法调用耗时

@RestController
@Slf4j
public class TestController {@RequestMapping("/trace")public String trace(int number) throws InterruptedException {number++;fun1(number);return "Hello World!";}private void fun1(int number) throws InterruptedException {TimeUnit.MILLISECONDS.sleep(10);number++;fun2(number);}private void fun2(int number) throws InterruptedException {TimeUnit.MILLISECONDS.sleep(300);number++;fun3(number);}private void fun3(int number) throws InterruptedException {TimeUnit.MILLISECONDS.sleep(20);}
}

trace

trace com.charles.web.TestController trace，监听TestController的trace方法。

访问wget http://localhost:7077/trace?number=1，可以看出trace和fun1方法的耗时。
trace命令只会匹配当前的方法，以及下一级方法。
trace -E com.charles.web.TestController trace|fun1|fun2|fun3

可以看出fun2方法耗时比较长。

watch

watch com.charles.web.TestController fun2 “{params,returnObj}” -x 2 -b，watch方法可以观察到入参，此时入参是3。

其它情况

从gc角度出发，是否存在大量gc，首先确定当前内存消耗情况，使用top命令或者查看设备监控管理系统，确定内存利用率达97%：

总结

CPU飙升问题定位的一般步骤是：
1.首先通过top指令查看当前占用CPU较高的进程PID；
2.查看当前进程消耗资源的线程PID： top -Hp PID
3.通过print命令将线程PID转为16进制，根据该16进制值去打印的堆栈日志内查询，查看该线程所驻留的方法位置。
4.通过jstack命令，查看栈信息，定位到线程对应的具体代码。
5.分析代码解决问题。