当收到告警，关于 java 应用所在主机、容器 CPU使用率 飙高，且无法恢复，应该从何开始排查呢。这里列举一种常规思路，以便应对在 CPU 异常时进行根因分析。

一、进入发生异常的主机，通过top命令查看资源占用情况： top

现在容器化部署的应用比较多，对于部署于K8S的应用，可通过 kubectl top pod pod名称查看（直接top看到的是宿主机的情况，该命令需要安装相应组件。1.8以下 heapter，metric-server）

根据看到CPU使用率高的 PID ，可通过 top -Hp PID 进一步查看线程情况。

二、查看java进程的线程信息： ps -mp pid -o THREAD,tid,time

ps命令功能是用于显示当前系统的进程状态。使用ps命令可以查看到进程的所有信息，例如进程的号码、发起者、系统资源使用占比（处理器与内存）、运行状态等等。其中

-m:显示所有的执行绪

-p PID : 指定程序识别码，并列出该程序的状况

在该步骤，找到占用CPU较高的线程号。即tid。

三、将线程号转为16 进制 ： printf “%xn” tid

在线程堆栈中（可通过 threaddump 看到），线程号是以16进制标识的。

四、打印线程堆栈信息，查询该线程号在堆栈中的情况： jstack pid |grep tid -A 100

五、根据 线程 堆栈情况，结合代码逻辑，具体分析原因。

除此之外，还可以通过jstat查看GC情况，Full GC 也会导致CPU飙高。如果发现GC不了（可通过 JVM 监控，gc 日志，jstat命令查看），可通过jmap 导出heapdump 进行分析(有些时候会在jvm 启动参数配置OOM 时自动生成heapdump：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof)。

常用命令如下：

jstat -gcutil PID 1000 #1秒更新一次GC情况，1000，单位ms,更新频率

jstat -gccapacity PID #用于查看新生代、老生代及持久代的存储容量情况

jmap -dump:live,format=b,file=/tmp/heapdump.hprof pid

分析时，需要参考JVM配置情况，可通过 ps -ef|grep java 或者jinfo PID 进行查看。