针对windows和linux两种不同的操作系统，判断方法略有差异。

一、针对windows操作系统

1.任务管理器-->详细信息-->cpu排序找到导致CPU持续高消耗的那个java进程对应的进程号

下图中导致CPU持续高消耗的java进程的pid进程号码是26488

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

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

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

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

进入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

二、针对linux操作系统

1.top命令找到导致CPU持续高消耗的那个java进程对应的进程号码

由top结果可知（按q可以退出top），导致CPU持续高消耗的java进程的pid进程号码是12241

2.pwdx 进程号码  查看进程号对应哪个实例

pwdx 12241可知该进程对应的实例是server1

3.cd 进入对应实例的logs目录下

（本案例是server1,本案例程序是安装在/var/kingdee目录下的，现场要根据实例情况而定，不能生搬硬套）

cd  /var/kingdee/eas/server/profiles/server1/logs    

4.ls -al | grep jvm列出实例的logs目录下所有的jvm日志

ls  -al | grep jvm

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

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

tail  jvm_gc_2022-05-17_16-47-15.log或tail -f   jvm_gc_2022-05-17_16-47-15.log

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

下图是OOM了

下图是非OOM