线上 Java 服务 CPU 飙高、频繁 Full GC 怎么排查？

详细解析#

先保留现场#

重启能让服务马上恢复，但线程栈、堆里的对象也一起没了。处理顺序一般是：

1. 有多台实例时，先把出问题的实例从负载均衡上摘下来，避免继续影响用户
2. 抓现场：连续几次线程栈、jstat 输出、GC 日志，必要时导出堆转储
3. 再重启或回滚，事后拿着现场慢慢分析

现场能不能拿到，很大程度取决于启动参数是否提前配好：

java -Xms4g -Xmx4g \
  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/heap_%p.hprof \
  -Xlog:gc*:file=/data/logs/gc.log:time,uptime,level,tags:filecount=5,filesize=20M \
  -jar app.jar

-Xlog 是 JDK 9 起的统一日志，格式是 -Xlog:标签:输出:装饰:输出选项，gc* 相当于 JDK 8 的 -XX:+PrintGCDetails，filecount、filesize 控制日志滚动。

CPU 飙高：从线程定位到代码#

Linux 命令部分见 线上服务器 CPU 或内存飙高怎么排查，这里只讲 Java 相关的部分：

1. top -H -p <pid> 找到 CPU 最高的几个线程，记下线程 ID（十进制）
2. 抓线程栈：jstack <pid> 或 jcmd <pid> Thread.print（官方文档把 jstack 标为实验性工具，Oracle 的排障指南推荐优先用 jcmd）
3. 在线程栈里按 nid 找到这个线程。JDK 17 及以前 nid 是十六进制，要先用 printf '%x\n' <tid> 转换；JDK 18 起改成直接打印十进制，可以直接搜
4. 隔几秒再抓两三次。始终停在同一段业务代码上、状态是 RUNNABLE 的线程，才是真正的热点

看栈时常见的几种情况：

频繁 Full GC：先看现象，再找对象#

jstat -gcutil <pid> 1000 10    # 每 1000 毫秒输出一次，共 10 次

主要看 O（老年代占当前容量的百分比）、YGC/FGC（新生代 GC 和 Full GC 的次数）、FGCT（Full GC 累计耗时）。几种典型现象：

• FGC 快速增长，每次 Full GC 后 O 都降不下来，并且越来越高：存活对象越来越多，多半是内存泄漏
• Full GC 后 O 能降下来，但很快又涨满：短时间内分配了大量对象，比如一次查询几十万行、导出大报表，或者新生代太小导致对象过早晋升
• GC 日志里反复出现 Metadata GC Threshold 这类和元空间有关的触发原因，jstat -gc 的 MU（元空间已用，单位 KB）一直涨：元空间不够，常见于不断动态生成类。-gcutil 的 M 列是相对当前已提交容量的百分比，接近 100% 不代表元空间到了上限
• GC 日志里 Full GC 的原因是 System.gc()：代码或依赖库主动调用了它

G1、Parallel 的 GC 日志里搜 Pause Full，能看到每次 Full GC 的原因和前后的内存占用。确认是对象问题后，导出堆转储：

jcmd <pid> GC.heap_dump /data/dump/heap.hprof          # 默认先触发一次 Full GC，只导出存活对象；加 -all 导出全部对象且不触发 GC
jmap -dump:live,format=b,file=/data/dump/heap.hprof <pid>   # 等价的老写法
jcmd <pid> GC.class_histogram | head -20                # 不导文件，先看哪些类的实例最多

用 MAT 打开堆转储：先看 Leak Suspects 报告，再看 Dominator Tree 找出"一个对象撑起了多大的内存"，最后对可疑对象看 Path to GC Roots，顺着引用链找到持有它的代码，比如一个只加不删的静态 Map、没有上限的本地缓存、没有 remove 的 ThreadLocal。各个内存区域和 GC 的原理分别见 JVM 的内存区域 和 垃圾回收。

常见原因对照#

用 Arthas 在线排查#

Arthas 通过 attach 进入目标 JVM，不用重启就能看线程、追踪方法耗时，要用和目标进程相同的用户启动：

curl -O https://arthas.aliyun.com/arthas-boot.jar
java -jar arthas-boot.jar               # 列出 Java 进程，输入编号后进入

dashboard                               # 实时面板：线程 CPU、堆和元空间、GC 次数和耗时
thread -n 3                             # 最忙的 3 个线程及其栈，默认按 200 毫秒的采样计算 CPU
thread -b                               # 找出阻塞了其他线程的线程（只支持 synchronized）
trace com.example.OrderService createOrder '#cost > 100'  # 只显示耗时超过 100 毫秒的调用，逐个子调用列出耗时
profiler start                          # 开始采样（默认 cpu 事件）
profiler stop --format flamegraph       # 停止并生成 HTML 火焰图
heapdump --live /data/dump/heap.hprof   # 导出堆转储
stop                                    # 用完彻底退出 Arthas；quit 只断开连接，Arthas 仍留在进程里

trace 每次只展开一层调用，想继续往下钻，就对耗时最长的子方法再 trace 一次。

面试官可能追问#

易错点#

• 先重启再排查，现场就没了；至少先抓几次线程栈和 jstat 输出
• jmap -dump:live、jcmd GC.heap_dump、GC.class_histogram 默认都会先触发 Full GC，在已经频繁 Full GC 的服务上执行，会让情况雪上加霜；后两者加 -all 可以跳过这次 GC，代价是结果里混有不可达的对象
• 只抓一次线程栈就下结论，可能刚好抓到一个偶然的瞬间
• 内存泄漏时调大 -Xmx 只能推迟问题，堆越大单次 Full GC 停顿还越长