Java垃圾回收中，大对象直接进入老年代由-XX:PretenureSizeThreshold阈值（字节）决定，仅Serial/ParNew收集器生效；超阈值则绕过Eden直接分配，但需老年代有足够连续空间，否则触发Full GC或OOM。
Java 垃圾回收器中，动态空间分配策略和大对象直接进入老年代的门槛，并不是由某个固定“开关”控制的，而是 JVM 根据运行时收集器类型、堆结构、历史晋升数据等综合决策的结果。理解的关键在于：它不是静态配置，而是自适应行为。
动态空间分配策略（主要是 TLAB 和 Eden 区分配）
Java 对象优先在 Eden 区分配，但并非直接向 Eden 整体申请内存，而是通过线程本地分配缓冲区（TLAB）实现无锁快速分配：
- 每个线程独享一块小内存（默认开启，可通过 -XX:+UseTLAB 控制），避免多线程竞争 Eden 的分配指针
- TLAB 大小由 JVM 动态估算：基于线程分配速率、Eden 空间大小、上一轮 GC 后的存活对象分布等；也可用 -XX:TLABSize 或 -XX:TLABWasteTargetPercent 干预
- 当对象大于 TLAB 剩余空间时，会尝试在 Eden 中直接分配（慢路径）；若 Eden 不足，则触发 Minor GC
- 如果对象实在太大（如超大数组），连 Eden 都放不下，JVM 就会绕过新生代，直接在老年代分配——这就是“大对象直接进入老年代”的起点
大对象直接进入老年代的门槛（-XX:PretenureSizeThreshold）
这个参数仅对 Serial 和 Parallel Scavenge 收集器有效，且只影响“是否跳过新生代”这一判断：
- -XX:PretenureSizeThreshold 设置一个字节数（如 1048576 表示 1MB），当新对象大小 ≥ 该值，JVM 直接在老年代分配（前提是老年代空间足够）
- 注意：CMS、G1、ZGC、Shenandoah 等现代收集器忽略此参数，它们用各自机制处理大对象（如 G1 的 Humongous Region，ZGC 的大页映射）
- 即使设置了该参数，也不代表所有大对象都进老年代——若老年代剩余空间不足，仍会先触发 Full GC 或抛出 OOM
真正起作用的其实是“晋升阈值”与“空间担保机制”
所谓“动态”，更多体现在对象何时从新生代晋升到老年代，而非仅看单次分配大小：
立即学习“Java免费学习笔记（深入）”；
- -XX:MaxTenuringThreshold 控制对象最多经历多少次 Minor GC 后晋升，默认是 15（CMS 是 6），但 JVM 可能提前晋升——当 Survivor 区无法容纳某次 GC 后的存活对象时，就会把超出部分直接送入老年代（动态年龄判定）
- 每次 Minor GC 前，JVM 会检查老年代可用空间是否 ≥ 新生代所有对象总大小（或历史平均晋升大小），即“空间担保机制”。不满足则直接触发 Full GC，避免晋升失败
- 所以，“大对象直入老年代”只是表象；背后是 JVM 在平衡分配效率、GC 频率、内存碎片和停顿时间之间的实时权衡
怎么观察和验证这些行为？
靠日志，而不是猜测：
- 加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 查看每次 GC 前后各代容量、对象大小分布
- G1 下启用 -Xlog:gc+heap=debug（JDK 10+）可看到 Humongous 分配详情
- JDK 8 可用 -XX:+PrintAdaptiveSizePolicy 输出 JVM 如何动态调整 Eden/Survivor 比例、TLAB 大小等
- jstat -gc <pid> 实时查看各区域使用量和 GC 次数，结合对象创建节奏分析是否频繁触发大对象分配
