共计 1944 个字符，预计需要花费 5 分钟才能阅读完成。
通常状况下，性能报告中只说 CPU 使用率高的时候，并不能帮忙定位问题。因为 CPU 高会有多种不同的状况。CPU 有五种状态 (us sy id wa st), 在 vmstat 中能显示进去，这个想必很多人都分明。在代码耗费 CPU 的时候（这也是通常性能剖析中会遇到的），是 US 状态的 CPU。当然还存在一种状况，就是代码产生的零碎调用特地高，这种状况下 SY 的 CPU 也会高（这种状况比拟少见，在我的职业生涯中只见过一次）。对于 JAVA 语言来说，咱们不须要特地简单的 profile 工具就能够做到定位到代码。
在写具体的分析方法之前，须要说一下线程的状态转换关系，咱们先来看一下零碎级的线程状态转换关系。
通过这个转换关系，能够看到，在线程产生之后，会先到 ready 的状态。在这个状态上是在期待 CPU 的。而在 runing 状态才是真正在 CPU 上执行的。请留神这个区别。
而 vmstat 显示的 r 列是包含了 ready 和 running 的线程（会因操作系统的不同有区别，然而对大部分 linux 零碎都是这样）。请留神这一点，因为网上有很多在写 vmstat 的解释的时候，说 r 列是示意正在运行的过程数或者说 r 是示意正在运行的线程数，这一点是不对的。给大家看一个例子（这也是上面要说到的例子）：
这是我的一个云服务器上正在运行的 top。能够看到以后 tasks（过程）中只有一个是 running 的状态的。而这时的 vmstat 呢？
这个服务器只有两个 CPU，所以如果 r 是说正在运行的过程或线程数的话必定是不正确的，因为两个 CPU 同时运行的最多是两个线程。
所以请记住，这个 r 值就包含了期待 CPU 的线程（也就是 ready 状态的）和正在运行的线程（也就是 running 状态的）。
当前有工夫再解释其余零碎级的线程状态，可能有些人感觉其余状态也没什么好解释的，然而在性能剖析中，线程的状态和一些性能计数器是有关联关系的，比如说 suspended 状态是 CPU 工夫片用完导致临时被换出；而 blocked 是因为要期待某个条件被满足而阻塞；并且这两种状态都有可能导致 CPU 使用率高。在剖析的过程中，这些信息给咱们的是一个方向。所以后面说到仅说 CPU 高不能帮忙剖析问题，因为 CPU 高有多种起因。
因为上面要说的是 JAVA，所以来看一下 JAVA 的线程状态转换关系。
从这个图中，咱们能够看到 JAVA 的过程有多种状态（具体状态的解释请自行搜寻），怎么看到这些状态都在干什么，就须要把栈打出来看。在栈中，能够看到具体对应的代码（对其余编译语言来说，要看看到正在运行的 code 也是要看栈的）。另外，在性能剖析中，栈的剖析是十分重要的一块内容，明天因为只是为了阐明从 CPU 高怎么定位到代码层，所以不过多解释线程的状态了，当前有工夫再写文章阐明。
实例：
上面来操作一下，首先执行一个耗费 CPU 的 JAVA 实例（实例是 7D Group 成员所编，有趣味入手操作的能够到网上轻易找一个小例子或本人编写一个）。查看 vmstat 的状态。
从上图能够看到右边窗口在执行一个耗费 CPU 的 Demo，而左边的窗口看到以后零碎的 CPU 曾经齐全被消耗掉了。过程号通过 top 命令就能够晓得：
上面就要看一下这个过程中的哪些线程耗费了 CPU。
通过 pidstat 能够看到（不好意思的是，pidstat 的截图被我笼罩掉了，又不想从新开始所以就不截图啦），有 10 个线程耗费着 CPU 资源。我把命令放在这里，有趣味的能够本人操作。
pidstat -p 10846 -u -d -t -w -h 1 1000
从上命令能够看到，有多个线程耗费着 CPU。线程 ID 是：10861、10862、10863 等等。
用 jstack 做一下 thread dump。
[root@7dgroup ~]# jstack -l 10846 > 10846.threaddump
再关上这个生成的文件。
nid 是指 native ID，对应着零碎级的 tid。只不过 TID 显示的是 10 过程的，NID 显示的是 16 进制的。
咱们转换一个线程号来查找。
[root@7dgroup ~]# printf %x’\n’ 10861
2a6d
再对应到 threaddump 文件中。
图片
显然能够去查这个 CPUTestThreadDemo.java 的第 13 行了。
从这个例子能够看出，对 java 的代码耗费 CPU 高的剖析只须要通过零碎级的命令和 JDK 自带的命令就能够实现了。因为这个例子非常简单，步骤比较清楚。但在理论剖析代码泛滥，逻辑简单的利用，有可能你看到的是 CPU 在线程上的耗费是在不停的切换的，所以就须要多做些 thread dump，一个个剖析。当然借助些工具剖析，通常能够让咱们在剖析简单的利用时事倍功半。
这里只阐明一个思路。
对 JAVA 的剖析来说，曾经有十分多的人写了十分多的文章了，我之所以写这个文章，是为了让文章能更系列一些。
