JVM---jstack分析Java线程CPU占用,线程死锁的解决

本文章主要演示在Windows环境,Linux环境也差不多。

一、分析CPU占用飙高

首先写一个Java程序,并模拟一个死循环。让CPU使用率飙高。CPU负载过大的话,新的请求就处理不了了,这就是很多程序变慢了甚至不能访问的原因之一。

下面是我这里的Controller,启动程序之后,开多个请求访问这个方法。死循环代码就不贴了,自己构造。我这里模拟的一个截取字符串的死循环。

/**

* 演示死循环导致cpu使用率飙高

* */

@RequestMapping("/loop")

public List<Long> loop(){

return getPartneridsFromJson();

}

启动程序,查看线程id,我这里是 796

开多个请求访问Controller方法,可以在任务管理器看到CPU不断增高。我开了7个窗口请求。Linux下可以通过 top命令查看CPU占用率。

现在发生了问题,开始定位问题。问题是我们手动构造的,实际生产环境肯定比这个复杂的多。

先把Java线程信息输出到指定文件,我这里就输出到桌面的cpu.txt文件中,如下

某线程部分属性说明:

jstack 796 > cpu.txt

Windows下要借助一个工具,查看系统进程以及线程的详细信息:

ProcessExplorer :下载地址:ProcessExplorer

解压,启动,长这样

熟悉的身影,PID为796的Java进程。CPU占用率最高。

在java.exe上右键选择Properties,在弹出的窗口选择Thread信息

可以看到7个CPU占用异常高的线程。这里的TID就是线程ID,不过是10进制的。刚刚我们jstack导出来的cpu.txt文件中的线程id是16进制的。

Linux下可以通过命令:

top -p 796 -H

查看线程的CPU占用率。

随便看一个,13812转换成16进制为:35f4,我们在cpu.txt搜一下这个线程

**可以发现,这个线程是运行中的状态,在执行indexOf方法。是JVMTuningController.getPartneridsFromJson这个方法。**这样就能定位到发生问题的位置了。实际生产情况要比这个复杂的多。就要慢慢分析了

二、分析线程死锁

先构造一个死锁方法,网上一搜一大把,我就不贴了。这是我的controller代码

/**

* 演示死锁 导致cpu使用率飙高

* */

@RequestMapping("/deadlock")

public String deadlock(){

deadLock();

}

程序跑起来,然后请求这个方法。

输出线程信息到deadLock.txt

jstack 15808 > deadLock.txt

打开deadLock.txt,看到最后面

以上这篇JVM---jstack分析Java线程CPU占用,线程死锁的解决就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持。

以上是 JVM---jstack分析Java线程CPU占用,线程死锁的解决 的全部内容, 来源链接: utcz.com/z/327858.html

回到顶部