分代收集理论的核心是“对象生命周期差异显著”，实战优化关键在于：让短命对象快速回收、长命对象少被扫描、中等寿命对象不卡晋升瓶颈；需根据变量真实存活特征反向设计分配与引用方式，避免误判导致不必要的Full GC。
分代收集理论的核心是“对象生命周期差异显著”，实战优化的关键在于：让短命对象快速回收、长命对象少被扫描、中等寿命对象不卡在晋升瓶颈。不是调参数就完事，而是根据变量实际存活特征，反向设计分配与引用方式。
识别变量真实生命周期，避免误判晋升
很多对象本该短命，却因引用方式不当提前进入老年代，引发不必要的 Full GC。比如：
- 缓存类 Map 中的 value 若是临时构建的 DTO，应确保其不被长期持有——用 WeakReference 包装 value，或改用 Caffeine 的自动过期策略
- 日志上下文（MDC）中放入的临时对象，要在 try-finally 或 try-with-resources 中显式 remove，否则线程复用时会意外延长生命周期
- 流式处理中用 Lambda 捕获的局部集合（如 List<String> list = new ArrayList<>(); stream.map(x -> list.add(x))），list 实际成为闭包引用，可能撑爆 Survivor 区
控制年轻代行为，减少 Minor GC 频率与晋升压力
Eden 区满即触发 Minor GC，但频繁 GC 往往不是堆小，而是对象“不该活那么久”。重点不是扩 Eden，而是截断异常存活路径：
- 避免在方法内创建大数组或大字符串拼接结果后直接返回——它们容易超过 Survivor 区容量，直接分配到老年代（Allocation Failure → Promotion）
- 设置合理的 -XX:MaxTenuringThreshold（默认15），对已知中等寿命对象（如用户会话 Session），可适当降低阈值（如设为4），让其早晋升、早稳定，避免反复复制消耗 CPU
- 启用 -XX:+AlwaysTenure 可强制所有存活对象直接进老年代（仅限极少数场景，如已知新生代无短命对象）
降低老年代干扰，隔离跨代引用影响
老年代对象引用新生代，会迫使 Minor GC 扫描整个老年代（违背弱分代假说）。常见诱因有：
- 静态集合（如 public static Map<String, Object> CACHE）被不断 put 新对象——新对象虽短命，但因被老年代静态引用而无法回收
- 监听器/回调注册未解绑，尤其在 Spring Bean 中使用 ApplicationEventPublisher 发布事件后，监听器若持有局部对象引用，也会形成跨代链
- 解决办法：用软引用（SoftReference）替代强引用缓存；监听器实现 DisposableBean 或 @PreDestroy 清理引用；对高频写入的全局 Map，改用 ConcurrentWeakHashMap
监控验证是否真按预期分代回收
光看 GC 日志不够，要结合对象年龄分布和晋升量判断策略是否生效：
- 开启 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，关注每次 Minor GC 后 “Desired survivor size” 和 “new threshold” 是否稳定
- 用 jstat -gc <pid> 观察 S0C/S1C 使用率是否均衡、YGC 次数与 YGCT 是否同步上升——若 S1 区长期空闲，说明对象基本一次就晋升，Survivor 设置可能失效
- 通过 JFR（Java Flight Recorder）录制事件，筛选 “Object Allocation Outside TLAB” 和 “Promotion” 事件，定位哪些类总在老年代分配
