线上快速定位CPU100%

连续两天下午CPU都达到了100%,第一次是因为打印日志时使用fastJson打印了很是大的保单对象，并且仍是在一个List中；第二次是因为循环保单集合时建立了大量的对象致使，因为第一种状况从日志中就能够看到，今天咱们就第二种状况进行分析。

步骤1、找到最耗CPU的进程

• 工具：top
• 方法：
  • 执行top显示进程运行信息列表
  • 输入P，进程按照CPU使用率进行排序

如上图所示，最耗CPU的进程PID为1

步骤2、找到最耗CPU的线程

• 工具：top
• 方法：
  • top -Hp 1 ,显示一个进程的线程运行信息列表
  • 输入P，线程按照CPU使用率排序

如上图，进程1中，最耗CPU的线程PID为2616

步骤3、将线程PID转化为十六进制

• 工具：printf
• 方法：printf "%x\n" 2616

如上图所示，2616对应的16进制是Oxa38，之因此要转换成十六进制，是由于堆栈里，线程ID是十六进制表示的。

步骤4、查看堆栈，找到线程在干吗

• 工具：pstack/jstack/grep
• jstack 2606 | grep 'Oxa38' -C5 --color
• 打印进程堆栈信息，经过线程ID过滤获得线程堆栈

jstack用于打印出给定的Java进程ID或core file或远程调试服务的Java堆栈信息

如上图找到了耗CPU高的线程对应的线程名称“pool-1-thread-1”，以及看到了该线程正在执行代码的堆栈

步骤5、分析线程的状态

线程的state

• 一、RUNNABLE:线程正在执行中，占用了资源，好比处理某个请求/进行计算/文件操做等
• 二、BLOCKED/Waiting to lock(需关注)：
  • 线程处于阻塞状态，等待某种资源(可理解为等待资源超时的线程)；
  • "waiting to lock "，即等待给xxx上锁，grep stack文件找locked 查找得到锁的线程；
  • "waiting for monitor entry" 线程经过synchronized(obj){……}申请进入了临界区，但该obj对应的monitor被其余线程拥有，从而处于等待。
• 三、WAITING/TIMED_WAITING{定时}(关注)：
  • "TIMED_WAITING (parking)":等待状态，且指定了时间，到达指定的时间后自动退出等待状态，parking指线程处于挂起中；
  • "waiting on condition"需与堆栈中的"parking to wait for (atjava.util.concurrent.SynchronousQueue$TransferStack)"结合来看。first-->此线程是在等待某个条件的发生，来把本身唤醒，second-->SynchronousQueue不是一个队列，其是线程之间移交信息的机制，当咱们把一个元素放入到 SynchronousQueue 中时必须有另外一个线程正在等待接受移交的任务，所以这就是本线程在等待的条件。
• 四、Deadlock(需关注):死锁，资源相互占用。

其余

线程状态为"waiting for monitor entry"

意味着它等待进入一个临界区，因此它在"Entry Set"队列中等待，此时线程状态通常是Blocked：java.lang.Thread.State:BLOCKED(on object monitor)

线程状态为"waiting on condition"

说明它在等待另外一个条件的发生，来把本身唤醒，或者干脆它调用了sleep(N),此时线程状态大体为如下几种： java.lang.Thread.State.WAITING(parking):一直等那个条件发生； java.lang.Thread.State.TIMED_WAITING(parking或sleeping)：定时的，那个条件不到来，也将定时唤醒本身

若是大量线程在"waiting for monitor entry"

多是一个全局锁阻塞住了大量线程 若是短期内打印的thread dump文件反映，随着时间流逝，waiting for monitor entry的线程愈来愈多，没有减小的趋势，可能意味着某些线程在临界区里呆的时间太长了，以致于愈来愈多新线程迟迟没法进入临界区。

若是大量线程在"waiting on condition"

多是它们又跑去获取第三方资源，尤为是第三方网络资源，迟迟获取不到Response，致使大量线程进入等待状态。 因此若是你发现有大量的线程都处在Wait on condition，从线程堆栈来看，正等待网络读写，这多是一个网络瓶颈的征兆，由于网络阻塞致使线程没法执行。

线程状态为"in Object.wait()":说明它得到了监视器以后，又调用了java.lang.Object.wait()方法。每一个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。当线程得到了 Monitor，若是发现线程继续运行的条件没有知足，它则调用对象（通常就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。 此时线程状态大体为如下几种： java.lang.Thread.State.TIME_WAITING(on object monitor); java.lang.Thread.State.WAITING(on object monitor); 通常都是RMI相关线程（RMI RenewClean、 GC Daemon、RMI Reaper），GC线程（Finalizer），引用对象垃圾回收线程（Reference Handler）等系统线程处于这种状态。