对象什么时候会进入老年代？
在Java应用运行过程中，对象的生命周期管理由JVM的垃圾回收机制负责。大多数对象诞生于新生代（Young Generation），而部分长期存活的对象最终会进入老年代（Old Generation）。了解对象何时进入老年代，对优化云环境下的内存使用和GC性能有实际帮助。
年龄阈值触发晋升
JVM会给每个在新生代中经历过一次Minor GC仍存活的对象增加一个“年龄”计数器。默认情况下，当这个年龄达到15，对象就会被转移到老年代。这个阈值可以通过参数 -XX:MaxTenuringThreshold 调整。
-XX:MaxTenuringThreshold=15比如在一个长时间运行的数据缓存服务中，某些热点数据包装对象反复躲过GC，年龄逐渐累积，最终顺利“退休”到老年代，避免重复复制开销。
大对象直接进入老年代
一些占用内存较大的对象，比如很长的字符串、大数组，如果在新生代分配反而会影响Minor GC效率。JVM提供了 -XX:PretenureSizeThreshold 参数，设定超过该大小的对象直接在老年代分配。
-XX:PretenureSizeThreshold=1048576这在处理云存储中频繁上传下载的大文件元数据时特别有用，避免新生代被大对象快速填满，导致频繁GC。
动态年龄判断机制
除了固定年龄阈值，JVM还会动态判断：如果在Survivor区中，某一年龄及以上的对象总大小超过了Survivor空间的一半，那么大于等于该年龄的所有对象都会被提前移到老年代，无需等到最大年龄阈值。
举个例子，假如多个请求同时生成了相似生命周期的缓存对象，它们在Survivor区积压，JVM会“察觉”到这些对象可能会长期存在，于是提前将它们集体晋升，提升内存管理效率。
空间分配担保
当进行Minor GC前，JVM会检查老年代最大可用连续空间是否大于新生代所有对象总大小。如果成立，说明即使新生代全部对象都要晋升，老年代也装得下，Minor GC可以放心执行。否则，会先触发一次Full GC做空间整理，或直接让部分对象提前进入老年代。
这种情况在突发流量场景下很常见，比如某个云存储接口突然被大量调用，短时间内创建大量临时对象，系统为了保证不因内存不足崩溃，会启用担保机制，允许对象提前“搬家”到老年代。