本文章主要演示在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，看到最后面
