步骤一：查看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日志删除。无需再手动收集heapdump日志（因为有最近几天自动产生heapdump日志的话，很可能OOM的原因是一样的，所以分析这个自动产生的就可以，如果要100%确定的话，那还是建议进行后面的步骤手动收集heapdump日志），如果没有这类日志或者没有最近几天产生的话，则需要进行后面的步骤手动收集heapdump日志

手动收集heapdump日志的步骤如下：

（1）打开oracle-jkd1.7\bin文件夹，选中jvisualvm.exe-->右键-->以管理员身份运行  调出图形界面

（本案例程序是安装在E:\kingdee\eas861文件夹下的，现场要根据实例情况而定）

（说明：oracle-jkd1.8\bin目录下的jvisualvm工具无法打开图形界面，需使用oracle-jkd1.7\bin目录下的jvisualvm工具）

（2）双击“com.kingdee.eas.tools.launcher.Start(pid 26488)”这一行-->点"监视”页签-->点击"堆Dump"

说明：本例中26488这个进程号占用的cpu高，故要双击“com.kingdee.eas.tools.launcher.Start(pid 26488)”这一行，现场要根据实际情况而定

（3）生成heapdump日志

生成这个日志需要一定的时间（一般不会超过一分钟）。完全生成后可以看到文件的路径及其名称（下图生成的路径在C:\Users\kingdee\AppData\Local\Temp\visualvm.dat\localhost_26488文件夹下，文件名是heapdump-1696670642832.hprof），可以将这个文件压缩后上传到ftp服务器上。  这个文件占用空间大，分析完成后可以将这个heapdump日志删除。

2.收集javacore日志

在jdk的bin文件夹下，输入cmd后按回车键,  再执行 .\jstack 进程号码  > 进程号码.txt

 （进程号码根据现场实际情况而定）

案例如下：

在jdk的bin文件夹下，输入cmd后按回车键,  再执行 .\jstack 进程号码  > 进程号码.txt

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

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

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

执行.\jstack   26488 > 26488.txt

生成的javacore日志26488.txt就在jdk的bin目录下，这个文件比较小，可以不用压缩。