优化 Java 集合对象过多导致的频繁 Full GC，核心是减少老年代对象堆积和调整垃圾回收器参数。适用于高并发服务端场景，风险在于不当的 JVM 参数调整可能引发更长的 STW 暂停。
先说结论：解决此类问题需先确认集合对象是否真的泄露或生命周期过长，再针对性修改代码或调整堆内存比例。
- 先定位：使用 jstat 和 Heap Dump 确认老年代占用来源是否为集合对象。
- 先做：清理无用引用、控制集合容量或切换低延迟垃圾回收器。
- 再验证：观察 GC 日志中 Full GC 频率和停顿时间是否下降。
命令速用版
以下命令用于快速收集 GC 状态和堆内存快照，需在服务器终端执行。
jstat -gcutil <pid> 1000：每秒打印一次 GC 统计，关注 O（老年代）使用率。
jmap -dump:format=b,file=heap.hprof <pid>：导出堆快照，用于离线分析对象分布。
grep "Full GC" gc.log：在日志中检索 Full GC 发生频率和时间点。
为什么会这样
Full GC 频繁通常是因为老年代空间不足以容纳存活对象，而集合对象往往是长期存活的重点嫌疑对象。
Java 集合类（如 HashMap、ArrayList）如果被静态变量、线程本地变量或长生命周期对象持有引用，垃圾回收器无法将其判定为垃圾。随着业务运行，集合不断扩容或存入数据，老年代使用率持续上升，触发 Full GC 清理。如果清理后空间仍不足，就会循环触发。
分步处理
步骤 1：监控 GC 状态
适用场景：线上服务出现卡顿或报警。操作动作：执行 jstat 命令观察 Old 区使用率。验证结果：若 Old 区持续接近 100% 且 Full GC 计数频繁增加，确认为老年代空间不足。风险边界：jstat 轻量级，对生产影响极小。
步骤 2：导出堆快照
适用场景：确认具体占用对象。操作动作：使用 jmap 导出 hprof 文件。验证结果：文件大小应与堆设置相当。风险边界：导出过程可能暂停 JVM，建议在流量低谷期操作或先扩容节点。
步骤 3：分析对象引用
适用场景：离线分析。操作动作：使用 MAT 或 JProfiler 打开 hprof 文件，查看 Dominator Tree。验证结果：找到占用内存最大的集合对象及其引用链。风险边界：分析大文件需要足够内存，避免分析工具 OOM。
步骤 4：代码优化与参数调整
适用场景：确认代码问题或参数不合理。操作动作：移除静态集合引用、设置集合初始容量、调整 -Xmx 和 -Xms。验证结果：代码提交后观察 GC 频率。风险边界：调整堆大小需重启服务，参数不当可能导致启动失败或更频繁 GC。
怎么验证是否生效
查看 GC 日志文件，对比优化前后的 Full GC 次数和平均停顿时间。使用监控平台观察老年代使用率曲线是否变得平稳，不再频繁触顶。业务侧确认接口响应延迟是否恢复正常。
常见坑
1. 静态集合缓存：使用 static Map 存储数据且无清理机制，导致内存只增不减。
2. ThreadLocal 未移除：线程池复用线程时，ThreadLocal 中的集合对象未被 remove，造成隐性泄露。
3. 监听器未注销：注册全局监听器后未注销，持有大量业务对象引用。
4. 盲目调大堆内存：若对象泄露，调大堆只能延缓 Full GC 发生，无法根治，且会增加单次 GC 停顿时间。
常见问题
Full GC 和 Minor GC 有什么区别？
Minor GC 回收新生代，速度快且频繁；Full GC 回收整个堆包括老年代，速度慢且应尽量避免。
堆快照文件太大无法导出怎么办？
可以使用 jmap 的 live 子选项仅导出存活对象，或临时增加堆内存参数后重启再导出。
切换 G1 垃圾回收器能解决吗？
G1 可控制停顿时间，但若对象泄露或内存确实不足，切换回收器无法根本解决问题，需配合代码优化。