一次性搞清楚线上CPU100%，频繁FullGC排查套路

这种情况我们查看 Dump 内存得到的文件即可判断，因为其会打印 GC 原因：

[Full GC (System.gc()) [Tenured: 262546K->262546K(349568K), 0.0014879 secs] 262546K->262546K(506816K), [Metaspace: 3109K->3109K(1056768K)], 0.0015151 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]  
[GC (Allocation Failure) [DefNew: 2795K->0K(157248K), 0.0001504 secs][Tenured: 262546K->402K(349568K), 0.0012949 secs] 265342K->402K(506816K), [Metaspace: 3109K->3109K(1056768K)], 0.0014699 secs] [Times: user=0.00 

比如这里第一次 GC 是由于 System.gc() 的显示调用导致的，而第二次 GC 则是 JVM 主动发起的。

总结来说，对于 Full GC 次数过多，主要有以下两种原因：

• 代码中一次获取了大量的对象，导致内存溢出，此时可以通过 Eclipse 的 Mat 工具查看内存中有哪些对象比较多。
• 内存占用不高，但是 Full GC 次数还是比较多，此时可能是显示的 System.gc() 调用导致 GC 次数过多，这可以通过添加 -XX:+DisableExplicitGC 来禁用 JVM 对显示 GC 的响应。

CPU 过高

在前面第一点中，我们讲到，CPU 过高可能是系统频繁的进行 Full GC，导致系统缓慢。

而我们平常也肯定能遇到比较耗时的计算，导致 CPU 过高的情况，此时查看方式其实与上面的非常类似。

首先我们通过 top 命令查看当前 CPU 消耗过高的进程是哪个，从而得到进程 id;然后通过 top -Hp 来查看该进程中有哪些线程 CPU 过高，一般超过 80% 就是比较高的，80% 左右是合理情况。

这样我们就能得到 CPU 消耗比较高的线程 id。接着通过该线程 id 的十六进制表示在 jstack 日志中查看当前线程具体的堆栈信息。

在这里我们就可以区分导致 CPU 过高的原因具体是 Full GC 次数过多还是代码中有比较耗时的计算了。

如果是 Full GC 次数过多，那么通过 jstack 得到的线程信息会是类似于 VM Thread 之类的线程。

而如果是代码中有比较耗时的计算，那么我们得到的就是一个线程的具体堆栈信息。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!