大对象直接进老年代是jvm分配时毫秒级判定的硬性路径，需同时满足：对象大小≥pretenuresizethreshold且超过eden最大连续空闲块；仅serial/parallel gc支持，g1/zgc等不适用。

大对象直接进老年代不是“偶尔发生”，而是 JVM 在分配那一刻就做出的硬性决定。它不走新生代，也不等 GC 触发，只要两个物理条件同时满足，就会跳过 Eden 和 Survivor，直奔老年代。

什么算“大对象”？

不是凭感觉，而是看参数和内存布局：

• -XX:PretenureSizeThreshold 是唯一开关，默认为 0（即关闭）。设成 4194304（4MB），那 ≥4MB 的对象才可能触发该机制
• 对象大小是 JVM 运行时估算的，包括对象头、字段、对齐填充等，数组还含元素总长度
• 注意：这个阈值只对 Serial 和 Parallel 系列 GC 生效；G1、ZGC、Shenandoah 完全无视它

为什么不能只看“够不够大”？

光超阈值还不够，必须同时满足空间条件：

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• Eden 区当前最大连续空闲块
• 例如 Eden 剩余 5MB，但被碎片切成 2MB + 3MB 两段，一个需 4MB 连续空间的对象仍会直入老年代
• 这不是“剩余空间不足”，而是“没有足够大的单块连续空间”——这是复制式 GC 的固有约束

怎么确认它真进了老年代？

别靠猜，靠日志证据：

• 启动时加参数：-XX:+PrintGCDetails -XX:+PrintTenuringDistribution
• 观察 gc.log：若某次 Minor GC 中 PSYoungGen 分配记录里没出现该对象，但 ParOldGen 使用量突增，基本可断定直入
• 配合 jstat -gc 或 JFR 采样，能定位到具体分配时刻的老年代增量

常见踩坑点

配置了却没生效？多半掉进这些坑里：

• 用了 -XX:+UseG1GC 却还设 PretenureSizeThreshold → 白配，G1 改用 -XX:G1HeapRegionSize 判定 Humongous Object
• Survivor 区太小，导致对象在 Minor GC 后无法容纳，被迫提前晋升 → 这属于“分配担保失败”，不是大对象直入
• 对象实际大小未达阈值（比如 String 底层 char[] 达标，但 String 对象本身很小）→ JVM 按实际分配单元判断，不是按引用类型

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南