线上服务CPU100%问题快速定位实战

题目

某服务器上部署了若干tomcat实例，即若干垂直切分的Java站点服务，以及若干Java微服务，突然收到运维的CPU异常告警。

问：如何定位是哪个服务进程导致CPU过载，哪个线程导致CPU过载，哪段代码导致CPU过载？

 

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

工具：top

方法：

执行top -c，显示进程运行信息列表

键入P (大写p)，进程按照CPU使用率排序

图示：



如上图，最耗CPU的进程PID为10765

 

步骤二：找到最耗CPU的线程

工具：top

方法：

top -Hp 10765，显示一个进程的线程运行信息列表

键入P (大写p)，线程按照CPU使用率排序

图示：



如上图，进程10765内，最耗CPU的线程PID为10804

 

步骤三：将线程PID转化为16进制

工具：printf

方法：printf “%x\n” 10804

图示：



如上图，10804对应的16进制是0x2a34，当然，这一步可以用计算器。

 

之所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的。

 

步骤四：查看堆栈，找到线程在干嘛

工具：pstack/jstack/grep

方法：jstack 10765 | grep ‘0x2a34’ -C5 --color

打印进程堆栈

通过线程id，过滤得到线程堆栈

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


图示：



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

转自：https://mp.weixin.qq.com/s/Xb1im4jG_Cobhas4q4YT1Q

接着分析分析线程的状态：

步骤五、分析线程的状态

线程的state

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

other      

线程状态为“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: TIMED_WAITING (on object monitor)；
        java.lang.Thread.State: WAITING (on object monitor)；
        一般都是RMI相关线程（RMI RenewClean、 GC Daemon、RMI Reaper），GC线程（Finalizer），引用对象垃圾回收线程（Reference Handler）等系统线程处于这种状态。
转自:http://www.cnblogs.com/zyhxhx/p/4564953.html