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

root用户下执行top命令截图  （按q可以退出top）

下图是java进程占用cpu比较高的情况（428.5），一般超过300可能就是比较高了

步骤二：判断jdk类型

root用户下执行ps -ef | grep osgi   | more

下图是oracle的jdk  （如果是ibm的jdk的话，下图红框部分会是ibm-jdk的字样）

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

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

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

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

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

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

判断过程如下：

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

如果没有大量连续的Full GC，证明是非oom，如果是大量连续FullGC的话，就是OOM

下图是非OOM

。

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

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

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

步骤四：非OOM日志收集

主要是收集各个线程占用cpu的情况和javacore日志，两者缺一不可

1.收集各个线程占用cpu的情况

ps   -mp    进程号码  -o   THREAD,tid,time   >   1.txt

进程号码指的是占用cpu高的那个进程号码，本例是12241，现场需根据实际情况而定，执行完成后会在当前目录下产生1.txt的这个文件，这个文件中就记录了各个线程占用cpu的情况。pwd命令可以查看当前目录。详细如下图：

2.收集javacore日志

（1）ps    -ef   |grep   osgi   |more      查看jdk bin目录的路径

（2）cd  进入jdk的bin目录

（3）jstack 实际的进程号  > 实际的进程号.txt  

案例如下图：

生成的txt文件就在jdk的bin目录下，本例是/var/kingdee/eas/oracle-jdk1.8/bin目录下

最后把1.txt和12241.txt发出来