Java进程CPU高负载排查步骤_java进程cpu使用率高排查_YouluBank的博客-CSDN博客

【问题定位】使用arthas定位CPU高的问题_arthas cpu高_秋装什么的博客-CSDN博客

CPU飙升可能原因

CPU 上下文切换过多。

对于 CPU 来说，同一时刻下每个 CPU 核心只能运行-个线程，如果有多个线程要执行，CPU 只能通过上下文切换的方式来执行不同的线程。上下文切换需要做两个事情：保存运行线程的执行状态；让处于等待中的线程执行这两个过程需要 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进程内所有线程的资源占用情况

<code>top -Hp 29706

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

使用jstack命令定位代码

线程号转换为16进制

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

<code>printf "%x\n" 30309

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

采用jstack命令导出线程快照

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

<code>jstack -l 29706 > ./jstack_result.txt

根据线程号定位具体代码

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

cat jstack_result.txt |grep -A 100 7665

根据搜索结果，判断应该是ImageConverter.run()方法中的代码出现问题

也可以直接采用jstack |grep -A 200 来定位具体代码

<code>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]

展示指定线程的线程栈

模拟查看方法调用耗时

<code>@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.分析代码解决问题。