老年代回收速度跟不上分配速度的根本原因是Mixed GC清理能力被压垮，需提前触发并发标记、收紧回收范围、减少无效晋升，并通过日志指标验证效果。
老年代回收速度跟不上分配速度，本质是 Mixed GC 的清理能力被“压垮”了——不是它不想清，而是标记没完成、回收集选得不准、或晋升太猛导致老年代持续膨胀。解决方向很明确：让并发标记更早启动、让每次 Mixed GC 更聚焦、从源头掐断无效晋升。
提前触发并发标记，别等堆快满了才动手
默认 IHOP=45% 太保守。当长期存活对象多时，老年代可能在堆总占用才 40% 时就已逼近极限，但 G1 压根不启动标记，自然没有后续 Mixed GC。应把 InitiatingHeapOccupancyPercent 调到 30%~35%，让标记周期提早介入。调完后盯日志里的 initiating occupancy 字段，确认真实触发点是否落在目标区间；低于 30% 易引发 Mixed GC 频繁，反而拖累吞吐。
收紧回收范围，只碰“值得清”的老年代 Region
Mixed GC 不是扫全量老年代，而是按“存活率低 + 回收收益高”原则挑 Region。默认设置太宽松，容易浪费时间扫描那些装满长期变量的“硬核 Region”：
- G1MixedGCLiveThresholdPercent=65：只回收存活对象 ≤65% 的 Region（默认 85%），跳过高存活率区域
- G1OldCSetRegionThresholdPercent=10：单次最多选老年代 Region 总数的 10%（默认无上限），防止单次压力过大
堵住晋升漏洞，减少老年代“被动扩容”
很多所谓“长期存活变量”，其实是本不该进老年代的：
- 缓存用 WeakReference/SoftReference 包装，并配合 ReferenceQueue 主动清理
- 批量加载改用 Stream.iterate().limit(n) 分页，避免万级 List 直接撑爆 Survivor 区而强制晋升
- 检查 ThreadLocal 使用场景，线程池中未调用 remove() 会导致 Value 对象长期滞留老年代
验证是否真有效，盯紧三个日志指标
不看 GC 日志等于没调：
- Mixed GC 耗时：是否稳定在 MaxGCPauseMillis 目标内（如 100ms），且波动小
- Old CSet 大小：日志中 old regions 数字是否下降，说明筛选更准、无效扫描减少
- Evacuation Failure：一旦出现，说明 Survivor 或老年代预留空间不足，需调大 G1ReservePercent（建议 10%~20%）
