本文章主要演示在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占用,线程死锁的解决就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持易盾网络。