转载

服务重启导致的Java服务抖动CPU占用高

今天后台组发现新上线的应用CPU总是会占用过高。（心里暗骂，新来的运维真无聊，闲着没事看top干啥）

首先发送命令 jps -lv 查询运行的进程pid=18182，

[admin@HCX-SER04 service-8072]$ jps 
19017 Jps
18827 jar

然后通过top -Hp 18182，查看哪个线程占用CPU过高。

[admin@HCX-SER04 ~]$ top -Hp 18827

top - 18:22:02 up 135 days,  4:09,  8 users,  load average: 0.14, 0.16, 0.07
Tasks: 137 total,   1 running, 136 sleeping,   0 stopped,   0 zombie
Cpu(s): 43.6%us,  5.2%sy,  0.0%ni, 50.2%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
Mem:   2054152k total,  1816632k used,   237520k free,    30808k buffers
Swap:  4194300k total,        0k used,  4194300k free,   415516k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                   
18838 admin     20   0 3373m 1.1g  15m R 39.9 55.9   0:22.16 java                                                                                                      
18871 admin     20   0 3373m 1.1g  15m S  4.7 55.9   0:04.73 java                                                                                                      
18881 admin     20   0 3373m 1.1g  15m S  0.3 55.9   0:00.05 java                                                                                                      
18905 admin     20   0 3373m 1.1g  15m S  0.3 55.9   0:00.05 java

将线程ID转为16进制

[admin@HCX-SER04 ~]$ python -c "print hex(18838)"
0x4996

然后使用命令jstack 18827 做线程dump

[admin@HCX-SER04 ~]$ jstack 18827 > 18827.log
[admin@HCX-SER04 ~]$

后面就简单了，把线程dump文件直接less打开，找到占用高的堆栈信息（这里是十六进制的线程ID）。

(END) 
"C2 CompilerThread0" #8 daemon prio=9 os_prio=0 tid=0x00007fb6e410c000 nid=0x4996 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Event Helper Thread" #7 daemon prio=10 os_prio=0 tid=0x00007fb6e4109800 nid=0x4995 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

原来是C2 CompilerThread。呵呵，这下简单了原来是C2编译器导致的。凡是服务器重启后，java都会把class文件进行编译优化，没办法，告诉他们这是无法避免的，java程序就是这样，上线还是晚上吧，免的服务抖动，大惊小怪。；）

原文 https://blog.csdn.net/xzknet/article/details/83383939

正文到此结束