记一次线上cpu占用率爆炸的事故! 完整FullGC、大对象排查一条龙!

线程篇——使用 jstack 分析问题

先看下线程zhuangt

# jstack 会尝试生成进程 ID 为 <pid>. 的 Java 进程的线程转储文件，并包含锁信息（-l 选项）
 jstack -l <pid>.

可以看到垃圾回收期的线程很活跃~

---

GC篇——jstat

看看gc的情况

# 将每2秒输出一次垃圾回收相关的数据，共输出5次
jstat -gc 1 2000 5

字段说明

字段	含义
S0C	Survivor 0 区的总容量（KB）
S1C	Survivor 1 区的总容量（KB）
S0U	Survivor 0 区已使用的容量（KB）
S1U	Survivor 1 区已使用的容量（KB）
EC	Eden 区的总容量（KB）
EU	Eden 区已使用的容量（KB）
OC	老年代的总容量（KB）
OU	老年代已使用的容量（KB）
MC	元空间的总容量（KB）
MU	元空间已使用的容量（KB）
CCSC	压缩类空间的总容量（KB）
CCSU	压缩类空间已使用的容量（KB）
YGC	年轻代 GC 次数
YGCT	年轻代 GC 总时间（秒）
FGC	Full GC 次数
FGCT	Full GC 总时间（秒）
CGC	并发 GC 次数
CGCT	并发 GC 总时间（秒）
GCT	所有 GC 的总时间（秒）

直接发现问题

• FGC 为 1868，Full GC 发生了 1868 次。
• FGCT 为 5360.070 秒，Full GC 总时间为 5360.070 秒。

FGC 为 1868，Full GC 次数过多，说明老年代空间不足或存在内存泄漏。

对象篇——jmap

打印大对象看看

jmap -histo:live <pid> > heap-histo.txt

生成堆转储文件

jmap -dump:live,format=b,file=heapdump.hprof <pid>

JProfiler分析

这里其实我已经发现了我们内存泄露的问题~