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

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

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

pwdx  PID进程号可以查看导致cpu持续高消耗的实例是哪一个

由上图知道PID进程号是14623，执行pwdx 14623可知导致cpu持续高消耗的实例是server1

步骤二：判断jdk类型

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

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

通过以上的截图基本可以确定是本例是ibm jdk，如果要100%确定的话可以进入到jdk的bin目录下，再执行./java -version进行确认。

截图如下：

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

jdk类型为oracle jdk 实例OOM导致CPU过高的处理办法请参考链接：

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

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

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

因为ibm-jdk下的jvm日志需通过工具分析才能知道是OOM还是非OOM，所以无法第一时间判断是OOM还是非OOM，建议cpu高时，可以先不判断是OOM还是非OOM，直接一并收集各类日志。

步骤四：日志收集

主要是收集收集各个线程占用cpu的情况、javacore日志、core日志。

在收集之前，可以在实例的bin文件夹下（eas/server/profiles/server#/bin\）检查是否有修改日期是最近的core开头的日志，如果有最近几天core开头的日志的话，则可能前几天也发生CPU持续高的情况，并且自动产生了日志，本次CPU持续高的原因很可能跟前几天的原因一致。可以将最新的那一个core上传到ftp服务器上。这个文件占用空间大，分析完成后可以将这个core日志删除。但如果要100%确认本次CPU持续高消耗的原因或没有最近的core日志。则需要进行后面的步骤手动收集日志。

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

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

(例如ps   -mp   14623  -o   THREAD,tid,time   >   1.txt)

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

本例中生成的1.txt这个文件在/root目录下。这个日志比较小可以云之家发送

2.收集javacore日志

kill -3  PID进程号码

生成的javacore日志在对应实例的bin目录下（eas/server/profiles/server#/bin）

由步骤一得知本例中PID进程号码是14623，导致cpu持续高消耗的实例是server1。

故执行kill -3 14623 回车

生成javacore日志在eas/server/profiles/server1/bin目录下，这个日志比较小可以云之家发送

3.收集core日志

（收集这个日志花的时间会比较长，收集过程中可能导致实例宕机，建议跟现场沟通好后再操作。）

kill -6  PID进程号码

生成的javacore日志在对应实例的bin目录下（eas/server/profiles/server#/bin）

由步骤一得知本例中PID进程号码是14623，导致cpu持续高消耗的实例是server1。

故执行kill -6 14623 回车

生成的core日志在eas/server/profiles/server1/bin目录下

注意：这个core日志是慢慢生成的，直到这个日志文件的大小不在变化时才证明这个日志生成完成了。具体可以参考下图。

这个日志比较大可以压缩后上传到ftp服务器上