JVM垃圾回收实战以“问题驱动”构建闭环，聚焦频繁Full GC、Minor GC异常、G1 Mixed GC抖动、元空间OOM四类典型故障，通过日志、指标、工具联动定位与修复。
JVM 垃圾回收综合实战演练项目，核心不是堆参数调来调去，而是围绕“问题驱动”构建闭环：从典型故障现象出发，定位 GC 行为异常，反推内存分配与对象生命周期问题，再通过参数、代码、工具三者联动验证和修复。整个过程要像查案一样——有日志、有证据、有假设、有验证。
明确目标场景，选一个真实可复现的故障点
别一上来就压测全链路。先聚焦一个高发、易观察、有代表性的切入点：
- 频繁 Full GC 且老年代持续增长：模拟静态集合缓存未清理、监听器未注销、线程局部变量长期持有大对象等典型泄漏模式；
- Minor GC 频率异常高（如每秒多次）：人为制造大量短命大对象（比如循环中 new byte[1MB]），观察 Eden 区快速打满、Survivor 区反复溢出、对象直接晋升老年代；
- G1 Mixed GC 停顿时间抖动剧烈：配置小堆 + 大 Region Size，注入跨代引用多、Remembered Set 扫描开销大的场景（如大量弱引用 HashMap + 频繁 put/remove）；
- 元空间持续增长最终 OOM：动态生成类（如 CGLIB 代理、Groovy 脚本热加载），不释放 ClassLoader，观察 Metaspace 的 GC 行为与 -XX:MaxMetaspaceSize 的实际约束效果。
搭建可观测性基线，让 GC “看得见、分得清、判得准”
没有日志和指标，调优就是蒙眼走路。启动 JVM 时必须带上关键诊断参数：
- 启用详细 GC 日志：-Xlog:gc*,gc+heap=debug,gc+metaspace=debug:file=gc.log:time,tags,uptime,level（JDK 10+ 推荐，替代旧版 -XX:+PrintGCDetails）；
- 暴露运行时指标：-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（可选，用于深度分析 JIT 与 GC 交互）；
- 配合 jstat 实时抓取：jstat -gc -h10
1s 观察各代容量、使用量、GC 次数与耗时变化节奏； - 用 VisualVM 或 JFR（Java Flight Recorder）录制 2~5 分钟运行片段，导出后重点看 “Garbage Collection” 和 “Memory Pool Usage” 时间线，识别 GC 触发前后的内存突变点。
动手复现 + 干预 + 验证，走通完整因果链
以“频繁 Full GC”为例，实战步骤如下：
- 写一段泄漏代码：比如在 static Map 中 put 不 remove 的业务对象，或注册了 Listener 却没 unregister；
- 用 -Xms256m -Xmx256m -XX:+UseG1GC 启动，压测几分钟，确认 gc.log 中出现连续多次 Full GC，且老年代使用率只升不降；
- 触发一次堆转储：jmap -dump:format=b,file=heap.hprof
，用 Eclipse MAT 分析 Dominator Tree，找到占用最大的泄漏根路径； - 改代码（如加 try-finally 清理 Map、显式 remove Listener），或加参数（如 -XX:MaxGCPauseMillis=200 引导 G1 更激进回收），重新跑，对比 GC 次数、停顿、内存曲线是否改善；
- 记录每次变更的参数、代码改动、观测结果，形成可回溯的实验日志。
延伸实战：把 GC 和其他 JVM 子系统串起来
真正复杂的线上问题，从来不是孤立的 GC 问题。演练中主动引入交叉影响：
- 在 GC 高峰期用 jstack
抓线程栈，看是否有大量线程阻塞在 synchronized 或锁竞争上，判断是 GC 导致 STW 还是业务锁拖慢了 GC 线程； - 开启 -XX:+UseStringDeduplication（G1）后，观察 StringTable 占比下降、Young GC 后存活对象减少，理解字符串去重如何降低 GC 压力；
- 用 Netty 写个简单服务，分配 Direct Buffer，同时监控 -XX:MaxDirectMemorySize 和 Native Memory Tracking (NMT) 输出，体会堆外内存不足如何间接触发更频繁的 Full GC（因 DirectByteBuffer Cleaner 依赖 ReferenceQueue 和 Finalizer 线程）。
