用top -c命令查看cpu占用高的进程

![在这里插入图片描述](https://img-blog.csdnimg.cn/12af3f060fb84ce98b24c7247546b50b.png
发现cpu占用为99%的进程pid为24857

用top -Hp 24857查看cpu占用最高的线程

发现占用cpu97.3%的线程id为24926

将24926转为16进制

通过jstack查看进程信息

24857为进程id
615e为线程的16进制id

jstack 24857 | grep "615e" -A 30

查处了这个问题
搜寻资料发现这是jdk8的一个bug,jdk9以后以解决，因此把jdk8换车了jdk11,cpu占用不在为100%，变为正常

从上面可以看到，ScheduledThreadPoolExecutor这个类的内部类DelayedWorkQueue的poll方法消耗了大量的cpu资源。

查看代码中用到ScheduledThreadPoolExecutor的地方：

int corePoolSize = 0;
ScheduledExecutorService executor = new ScheduledThreadPoolExecutor(corePoolSize);

这里声明了一个corePoolSize为0的线程池，这是有点诡异的地方，但是是允许的。

然而，问题就出在这个诡异点，这里触发了java的一个bug：

JDK-8129861：

ScheduledThreadPoolExecutor with corePoolSize = 0 causes 100% load on one CPU core

该bug即使用corePoolSize为0的ScheduledThreadPoolExecutor，会导致cpu飙升，已在java 9修复。具体描述请参见：

https://bugs.openjdk.java.net/browse/JDK-8129861

其他调优命令

S0：年轻代中第一个 survivor（幸存区）已使用的占当前容量百分比
S1：年轻代中第二个 survivor（幸存区）已使用的占当前容量百分比
E：年轻代中 Eden 区已使用的占当前容量百分比
O：老年代已使用的占当前容量百分比
M：元数据区使用比例
CCS：压缩使用比例
YGC：从应用程序启动到采样时年轻代中 gc 次数
YGCT：从应用程序启动到采样时年轻代中 gc 所用时间（单位秒）
FGC：从应用程序启动到采样时老年代 full gc 次数
FGCT：从应用程序启动到采样时老年代 full gc 所用时间（单位秒）
GCT：从应用程序启动到采样时 gc 用的总时间（单位秒）

最后使用 JDK 自带的工具，JAVA_HOME/bin/jvisualvm.exe工具分析快照