分代收集若配置不当会引发性能瓶颈：新生代过小导致Minor GC频繁，Survivor不足迫使对象提前晋升加剧老年代压力；老年代碎片化或回收器不匹配易触发Full GC；Metaspace无节制增长也会诱发Full GC。
分代收集本身是为提升 GC 效率而设计的，但若配置或使用不当，反而会成为 JVM 性能瓶颈的源头。核心问题不在于“是否分代”，而在于各代之间的边界、对象晋升逻辑与回收节奏是否匹配实际业务特征。
新生代过小导致频繁 Minor GC
Eden 区太小，新创建对象很快填满，触发高频 Minor GC；Survivor 空间不足时，本该在年轻代内回收的对象被迫提前晋升到老年代，加剧老年代压力。
- 典型现象：YGCT（年轻代 GC 时间）占比高，GC 日志中 Minor GC 间隔短于 100ms
- 建议：通过 -XX:NewRatio 或直接用 -Xmn 显式设置年轻代大小；观察 jstat 输出的 E（Eden 使用率）和 S0/S1 比值，确保 Survivor 能容纳至少 90% 的存活对象
- 示例：对高创建速率的服务（如实时订单系统），可将年轻代设为堆的 40%～60%，避免 Eden 频繁耗尽
对象过早晋升至老年代
当 Survivor 区无法容纳一次 Minor GC 后的存活对象，或对象年龄达到阈值（默认 15），就会晋升到老年代。若大量中短期对象（如中间 DTO、缓存 key）频繁晋升，老年代会快速堆积，触发频繁 Full GC。
- 典型现象：FGC（Full GC）次数上升，老年代使用率（OGU/OGC）持续增长且回收效果差
- 建议：用 -XX:MaxTenuringThreshold 控制晋升年龄；结合 -XX:+PrintGCDetails 查看每次 GC 后的 “age” 分布；必要时启用 -XX:+AlwaysTenure（慎用）或 -XX:+UseAdaptiveSizePolicy 让 JVM 动态调整
- 注意：Spring AOP、动态代理、JSON 序列化等场景易产生临时大对象，可能直接分配到老年代（-XX:PretenureSizeThreshold 可干预）
老年代碎片化与回收器不匹配
SerialOld、ParallelOld 等基于标记-整理的回收器虽能压缩空间，但 STW 时间长；CMS 虽并发，但存在浮动垃圾和 Concurrent Mode Failure 风险；若老年代长期处于高水位且碎片严重，即使未满也可能因无法分配大对象而触发 Full GC。
- 典型现象：老年代使用率未达 95%，却频繁发生 Full GC；GC 日志中出现 “promotion failed” 或 “concurrent mode failure”
- 建议：对延迟敏感服务优先选用 G1 或 ZGC；G1 需关注 -XX:MaxGCPauseMillis 和 -XX:G1HeapRegionSize；ZGC 要求 JDK 11+，且需确认操作系统支持大页（hugetlbfs）
- 关键检查点：用 jmap -histo 或 MAT 分析老年代中长期驻留对象类型，识别是否为缓存未清理、监听器未注销、线程局部变量泄漏等真实业务问题
元空间（Metaspace）无节制增长
虽然元空间不属于传统“分代堆”，但它与类加载行为强相关。大量动态生成类（如 Groovy 脚本、MyBatis Mapper、Spring CGLIB 代理）会导致 Metaspace 持续扩容，最终触发 Full GC（JDK 8+ 中 Metaspace 耗尽会引发 OutOfMemoryError: Metaspace，并伴随一次 Full GC）。
- 典型现象：Metaspace 使用率（MU/MC）接近 -XX:MaxMetaspaceSize，且持续上升；jstat 中 MGC（Metaspace GC 次数）增加
- 建议：显式设置 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize（如 256m/512m），避免初始频繁扩容；监控类加载数量（jstat -class PID）
- 排查方向：检查是否重复定义相同名称但不同 ClassLoader 的类；确认框架是否开启过多运行时字节码增强
