大量年龄≥15非长生命周期对象触发Full GC如何做JVM调优

你的核心判断是对的：这些熬到年龄阈值晋升老年代的对象，本质都是中短生命周期对象，本该在年轻代就被回收，根本不该进老年代。
先纠正一个常见误区：Java对象头里存分代年龄的位段只有4bit，能表示的最大值就是15，根本不存在年龄16、17、18的对象，年龄到15的对象下一次Minor GC会直接进入老年代。
结合你贴的配置算下内存分配，问题逻辑非常清晰：

• 堆固定6G，NewRatio=1，年轻代、老年代各分配3G
• SurvivorRatio=4，也就是Eden和单个Survivor的容量比是4:1，算下来Eden占2G，两个Survivor区各512M
  你现在设置MaxTenuringThreshold=15，等于要求对象在Survivor区熬过15次Minor GC才能晋升。如果业务里存在大量对象的生命周期刚好比「15次Minor GC的总间隔」长一点，又不是Spring Bean、永久缓存这种存活时间以小时/天计算的常驻对象，就会出现：
  对象刚好熬够15次GC被送入老年代，转脸就失去引用成为垃圾，但CMS默认等老年代占用到75%才启动回收，这些垃圾就会持续在老年代堆积。等老年代快被占满、或者CMS回收速度赶不上对象晋升速度触发Concurrent Mode Failure，就会退化为全停顿的Full GC，这时候这些刚晋升的垃圾被一次性清理，就出现了你观察到的Full GC后老年代从2390M骤降到800M的现象——这剩下的800M才是老年代里真正的常驻对象，被回收的1500M+全是错误晋升的短生命周期对象。
  另外需要注意：MaxTenuringThreshold=15只是年龄晋升的上限阈值，不是强制触发条件。JVM默认配置下只要Survivor区对象占用率超过50%（由TargetSurvivorRatio参数控制），就会提前把年龄较大的对象往老年代晋升，哪怕没到15的阈值，这会进一步加速短生命周期对象进入老年代。

按优先级从高到低调整即可：

1. 优先优化年轻代空间配置，让短生命周期对象尽量留在年轻代被回收
   • 把-XX:SurvivorRatio=4修改为-XX:SurvivorRatio=2，调整后Eden区占1.5G，单个Survivor区占768M，更大的Survivor空间可以避免因为容量不足触发的提前晋升，让存活对象有足够空间留在年轻代等待被回收
   • 把-XX:MaxTenuringThreshold=15修改为-XX:MaxTenuringThreshold=6，CMS收集器下年龄阈值设到15的收益极低，6是生产环境验证过的合理经验值，既可以避免对象在两个Survivor之间来回复制带来的不必要性能开销，也不会让存活时间太短的对象过早进入老年代
   • 新增参数-XX:TargetSurvivorRatio=80，提高Survivor区的利用率阈值，默认50%的配置过于保守，只要Minor GC后存活对象能完整放入Survivor区，就不要触发提前晋升
2. 调整CMS触发阈值，避免并发模式失败触发Full GC
   把-XX:CMSInitiatingOccupancyFraction=75修改为-XX:CMSInitiatingOccupancyFraction=68，适当提前CMS并发回收的触发时机，避免老年代空间增长过快导致CMS还没完成回收就被填满，触发停顿时间更长的Full GC。
3. 可选：根据对象分配速率微调年轻代大小
   如果调整上述参数后仍然有较多短生命周期对象晋升，可以把-XX:NewRatio=1修改为-XX:NewRatio=0.8，也就是老年代和年轻代的容量比为0.8:1，算下来年轻代约3.3G，老年代约2.7G。更大的Eden区可以拉长Minor GC的间隔，让对象在年轻代的停留时间变长，更容易在Minor GC阶段就被回收。注意不要把年轻代设得过大，避免Minor GC的停顿时间超出业务可接受范围。
4. 业务层面排查中短期临时对象来源
   建议在老年代占用涨到2G左右时dump堆快照，用内存分析工具检查晋升到老年代的对象类型，重点排查：
   • 本地缓存的过期时间是否设置过长
   • 异步任务、请求上下文是否存在持有引用过久、ThreadLocal未清理的问题
   • RPC/HTTP客户端、数据库连接池是否存在不必要的业务对象引用持有
     从代码层面减少这类生命周期在几十秒到数分钟的临时对象，效果远好于单纯调整JVM参数。

内容的提问来源于stack exchange，提问作者Feng Kai