EAS Cloud应用服务器为windows，jdk类型为Oracle jdk 实例OOM导致CPU持续高消耗的处理办法

步骤一：查看java进程占用cpu的高低情况

任务管理器-->详细信息-->cpu排序

下图是java进程占用cpu比较高的情况（55），如果是持续比较高就需要关注。

步骤二：判断jdk类型

1.选中占用cpu高的这个java进程-->右键-->打开文件所在的位置  可以进入jdk的bin文件夹

可以看到本例的jdk是oracle jdk，版本是1.8  （如果是ibm jdk的话，如下画红线的地方会是ibm字样）

一般这样就可以确定本例是oracle jdk，版本是1.8了，如果要100%确定的话，还可以按如下的步骤进行：

在jdk的bin文件夹下，输入cmd后按回车键,  再执行 .\java -version

注意：要在jdk的bin文件夹下，输入cmd后按回车键，此时cmd进入的才是jdk的bin文件夹

确认此时cmd是进入jdk的bin文件夹。

执行.\java   -version

下图是使用了oracle的jdk，64bit 1.8版本 （如果是ibm的jdk的话，会有是IBM的字样输出）

本文主要介绍jdk类型为Oracle jdk 实例OOM导致CPU过高的处理办法。

jdk类型为ibm jdk 实例对应的java程序导致CPU过高的处理办法请参考链接：

EAS Cloud应用服务器为windows，jdk类型为ibm jdk 实例对应的java程序导致CPU过高的处理办法

步骤三：判断是OOM还是非OOM导致cpu高

判断依据：

OOM：占用cpu高的java进程对应实例的最新的jvm日志末尾有大量连续的Full GC

非OOM: 占用cpu高的java进程对应实例的最新的jvm日志末尾没有大量连续的Full GC

判断过程如下：

1.任务管理器-->详细信息-->cpu排序找到占用cpu高的那个java进程对应的进程号

下图中占用cpu高的java进程的pid进程号码是26488

2.在控制台--"应用服务器"页签上查看进程号对应哪个实例

由下图可知该26488的进程号码对应的实例是server1（有时候找不到的进程号码的话要刷新一下）

3.进入对应实例的logs文件夹下

（本案例是server1,本案例程序是安装在E:\kingdee\eas861文件夹下的，所以要进入实例1的logs目录下，现场要根据实例情况而定，不能生搬硬套）

进入E:\kingdee\eas861\eas\server\profiles\server1\logs文件夹

4.找到实例的logs目录下所有的jvm开头的日志

建议按“名称”排序找到所有jvm开头的日志

5.检查最新的那个jvm日志末尾是否有大量连续的Full GC

实例的logs目录下一般有很多jvm开头的日志，要检查最新的那一个，最新的那一个才是现在正在使用的，如果现场jvm只有一个的话那就查看那一个就可以。本案例中最新的jvm日志名是jvm_gc_2023-10-07_16-06-08.log

用记事本之类的文本工具打开这个最新的jvm日志，拖到文件末尾

如果是大量连续的Full GC，证明是oom了，否则就是非OOM

下图是OOM了

本文主要介绍实例OOM导致CPU过高的处理办法。

实例非OOM导致CPU过高的处理办法请参考链接：

EAS Cloud应用服务器为windows，jdk类型为Oracle jdk 实例非OOM导致CPU过高的处理办法

步骤四：OOM后日志收集

主要是收集heapdump日志和javacore日志

1.收集heapdump日志

在收集之前可以检查下实例的bin文件夹下（eas\server\profiles\server#\bin文件夹）是否有修改日期为最近几天的以javaheapdump日志或heapdump日志或core日志开头的日志。如果有最近几天的话，直接将最新的那一个压缩上传到ftp服务器上。这个文件占用空间大，分析完成后可以将这个heapdump