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

一、分析CPU占用飙高

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

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

/**
* 演示死循环导致cpu使用率飙高
* */
@RequestMapping("/loop")
public List 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占用,线程死锁的解决就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持云海天教程。