面试记录 2026-10-16
题目：数据倾斜导致的频繁FullGC问题排查
难度：high
标签：practice/debug, network/debug, jvm/gc, difficulty/high
评分：⭐⭐☆☆☆（2/5）
我的回答
数据倾斜下导致频繁fgc,需要首先查看下是否是流量倾斜,是否是有热点内容访问到某一台机器,导致请求都倾斜到一台服务上;
前置应该是发现了一组集群中某一台机器出现频繁fgc,然后可以先查看服务器负载的看板,看是否是请求流量发生倾斜,如果是请求流量出现的倾斜,那么需要调整前置的负载均衡算法,将流量平均下;
如果流量层没有问题,但是某台机器出现频繁fgc,那么使用jmap或者arthas导出服务的内存快照,使用jstack导出线程快照,检查下内存对象分配的情况;
确认具体是什么样的原因导致的频繁fgc;定位到具体的方法,和内容;然后对应进行分析处理
点评
优点：
- 先排查流量倾斜的意识好（热点内容导致单台机器压力）
- 提到 jmap/jstack 导出内存快照和线程快照
- 排查顺序基本正确（流量层 → JVM 层）
不足：
- 缺 GC 日志分析：未提 jstat -gcutil、GC 日志（pause time、heap usage 趋势）
- 缺 heap dump + MAT 分析：未提 MAT Dominator Tree 分析大对象、泄漏报告定位内存泄漏
- 缺 profiler 热点方法定位：未提 async-profiler/arthas profiler 看热点方法火焰图
- 缺具体指标：未提 FullGC 频率、STW 耗时、BLOCKED 线程数等关键指标
- 排查步骤过于笼统：未形成"监控 → GC 日志 → 线程 dump → profiler → heap dump"标准路径
补充：GC 排查五步标准路径——监控告警 → GC 日志分析 → 线程 dump → profiler 热点 → heap dump 分析。
完整讲解
第一部分：知识重点剖析
核心考点定位：考察 GC 排查的完整工具链（GC 日志 + heap dump + profiler）和标准排查路径。
知识点拆解：
- GC 排查五步标准路径：
- Step1 监控告警：CPU > 60% 预警、FullGC > 1 次/小时告警、STW > 500ms 严重、BLOCKED > 50 线程、堆使用率 > 80%
- Step2 GC 日志分析：-Xlog:gc*:file=gc.log 看 pause time/heap usage 趋势、jstat -gc <pid> 1000 看 GC 频率、jstat -gccause <pid> 看 GC 原因
- Step3 线程 dump：jstack <pid> 看线程状态、BLOCKED 线程卡在哪个 synchronized、RUNNABLE 线程在做什么是 CPU 飙高主因
- Step4 profiler 热点：async-profiler/arthas profiler start --event cpu 看热点方法火焰图、定位循环内频繁创建大对象
- Step5 heap dump 分析：jmap -dump:live,format=b,file=heap.hprof <pid> 导出堆快照、MAT Dominator Tree 看大对象、泄漏报告定位内存泄漏
- 数据倾斜导致 FullGC 的根因：
- 流量倾斜：热点内容导致单台机器压力，对象创建速度快于回收速度
- 内存泄漏：某个方法或类不断创建对象但不释放，老年代持续增长
- 大对象频繁创建：循环内频繁创建大对象（如大数组、大 Map），导致老年代快速增长
- 修复方案：
- 流量倾斜：调整负载均衡算法（一致性哈希、最少连接数）、热点数据缓存、读扩散
- 内存泄漏：修复代码（清理缓存、关闭资源）、增大堆内存（治标不治本）、调整 GC 参数
- 大对象频繁创建：对象池化、减少循环内对象创建、使用栈对象（不逃逸分析）
第二部分：考察方向与延伸递进
考察方向：
- 深度：五步标准路径、GC 日志分析、heap dump + MAT 分析
- 广度：与 Q9（P99 飙高）、Q10（CPU95 线程 800）的排查方法对比
- 应用：线上 GC 排查实战、预警机制设计
延伸递进面试题：
- 如何分析 GC 日志？
- 解答要点：-Xlog:gc*:file=gc.log 开启 GC 日志，看 pause time（STW 耗时）、heap usage（堆使用趋势）、GC 原因（allocation failure/ metaspace 等）
- MAT 如何分析 heap dump？
- 解答要点：Dominator Tree 看大对象（占据最多内存的对象）、泄漏报告（Leak Suspects）定位内存泄漏、Histogram 看对象数量直方图
- 数据倾斜如何导致 FullGC？
- 解答要点：热点内容导致单台机器压力，对象创建速度快于回收速度，老年代快速增长，触发 FullGC
第三部分：面试者参考回答（三步法口语化，300-400 字）
【一句话结论】
面试官您好，GC 排查五步标准路径——监控告警 → GC 日志分析 → 线程 dump → profiler 热点 → heap dump 分析。
【三点展开】
第一，Step1 监控告警：CPU > 60% 预警、FullGC > 1 次/小时告警、STW > 500ms 严重、BLOCKED > 50 线程、堆使用率 > 80%。先确认是不是流量倾斜（热点内容导致单台机器压力），如果是调整负载均衡算法。
第二，Step2-3 GC 日志 + 线程 dump：-Xlog:gc*:file=gc.log 看 pause time/heap usage 趋势，jstat -gc <pid> 1000 看 GC 频率，jstat -gccause <pid> 看 GC 原因。jstack <pid> 看线程状态，BLOCKED 线程卡在哪个 synchronized，RUNNABLE 线程在做什么是 CPU 飙高主因。
第三，Step4-5 profiler + heap dump：async-profiler/arthas profiler start --event cpu 看热点方法火焰图，定位循环内频繁创建大对象。jmap -dump:live,format=b,file=heap.hprof <pid> 导出堆快照，MAT Dominator Tree 看大对象，泄漏报告定位内存泄漏。
【一句边界】
当然，排查要形成标准路径，不要凭直觉。流量倾斜先调整负载均衡，内存泄漏要修复代码（不是增大堆内存），大对象频繁创建要对象池化。预警机制要提前设置（CPU > 60% 预警、FullGC > 1 次/小时告警），避免线上事故。