连续两天下午CPU都达到了100%,第一次是由于打印日志时使用fastJson打印了非常大的保单对象，而且还是在一个List中；第二次是由于循环保单集合时创建了大量的对象导致，由于第一种情况从日志中就可以看到，今天我们就第二种情况进行分析。
步骤一、找到最耗CPU的进程
- 工具：top
- 方法：
- 执行top显示进程运行信息列表
- 输入P，进程按照CPU使用率进行排序
步骤二、找到最耗CPU的线程
- 工具：top
- 方法：
- top -Hp 1 ,显示一个进程的线程运行信息列表
- 输入P，线程按照CPU使用率排序
步骤三、将线程PID转化为十六进制
- 工具：printf
- 方法：printf "%x\n" 2616
步骤四、查看堆栈，找到线程在干嘛
- 工具：pstack/jstack/grep
- jstack 2606 | grep 'Oxa38' -C5 --color
- 打印进程堆栈信息，通过线程ID过滤得到线程堆栈
jstack用于打印出给定的Java进程ID或core file或远程调试服务的Java堆栈信息
步骤五、分析线程的状态
线程的state
- 1、RUNNABLE:线程正在执行中，占用了资源，比如处理某个请求/进行计算/文件操作等
- 2、BLOCKED/Waiting to lock(需关注)：
- 线程处于阻塞状态，等待某种资源(可理解为等待资源超时的线程)；
- "waiting to lock "，即等待给xxx上锁，grep stack文件找locked 查找获得锁的线程；
- "waiting for monitor entry" 线程通过synchronized(obj){……}申请进入了临界区，但该obj对应的monitor被其他线程拥有，从而处于等待。
- 3、WAITING/TIMED_WAITING{定时}(关注)：
- "TIMED_WAITING (parking)":等待状态，且指定了时间，到达指定的时间后自动退出等待状态，parking指线程处于挂起中；
- "waiting on condition"需与堆栈中的"parking to wait for (atjava.util.concurrent.SynchronousQueue$TransferStack)"结合来看。first-->此线程是在等待某个条件的发生，来把自己唤醒，second-->SynchronousQueue不是一个队列，其是线程之间移交信息的机制，当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。
- 4、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）等系统线程处于这种状态。
