JVM优化调试使用心得与线上CPU100%原因分析

因为线上系统遇到CPU100%的问题，这种问题在流量较大时比较常见，因为JDK自身有很多JVM调试工具，如jps、jstack、jmap、jhat、jstat等使用工具，在实际工作中使用这些工具进行调试是十分必要的，一般通过以下步骤就能定位并解决CPU100%的问题，文章是自己很早写的，现在重拾一下，下面只做简单介绍，这些都可以在线上服务器上执行。

一、 jstack

    jstack用来查Java进程内的线程堆栈信息。语法格式如下：

1	jstack [option] pid

-l，除了堆栈打印出额外的锁信息，在发生死锁时可以用jstack -l pid来观察锁持有情况

-m mixed mode，不仅会输出Java堆栈信息，还会输出C/C++堆栈信息（比如Native方法）

在Deploy里面的jstack导出的堆栈信息如下，我们在自动部署里面只使用-l命令，可以看到进程为30086，在堡垒机里面同样是此进程。

图1 自动部署平台jstack -l堆栈信息

图2 堡垒机查看应用进程id

由于jstack导出的栈信息比较多，通过这些信息可以定位到当前所有线程的运行状况、锁状态等等。

另外如果线上发生cpu使用过高的情况，jstack则可以快速定位到线程堆栈，具体的操作思路是获java进程中最耗费cup的线程，并得出其堆栈信息，根据堆栈定位到具体代码，这在JVM性能调试中使用得很多，这个操作得再堡垒机上运行.

 第一步先找出应用的进程ID，这个在上文已经说过，本文使用的是是30086：

接下来得到当前进程内最耗费CPU的线程，使用top -Hp 30086，输出如下：

图3 查看最耗时的线程

  TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为30531的线程，用

printf "%x\n" 30531

  得到30531的十六进制值为7743，之后使用jstack它用来输出进程30531的堆栈信息，然后根据线程ID的十六进制值grep，如下：

jstack 30531| grep 7743