大对象直入老年代旨在避开年轻代复制开销、减轻Eden压力、防止Survivor溢出导致的提前晋升；JVM按单次连续分配字节数（含对象头、字段、对齐填充）判定大对象；参数-XX:PretenureSizeThreshold仅对Serial/ParNew有效，G1需用-XX:G1HeapRegionSize；须确保老年代有足够连续空间，否则触发Full GC；代码层减少大对象生成比调参更根本。
大对象直接进入老年代，不是为了“避免年轻代 GC”，而是为了**避开年轻代复制开销、减少 Eden 区压力、防止 Survivor 溢出导致的提前晋升**。真正要防的，是小大对象（比如 1.2MB）卡在阈值边缘反复复制，或因 Survivor 不足被“误推”进老年代——这才引发年轻代 GC 频繁且低效。
确认哪些对象算真正的大对象
JVM 只看单次连续分配所需字节数，包括对象头（12 字节）、字段数据、对齐填充（按 8 字节对齐）。例如：
- 算大对象：new byte[4_000_000]（≈4MB）、new char[2_000_000]（≈4MB）
- 不算大对象：new HashMap<>()（本身仅几百字节）、new String("hello")（底层 char[] 很小）
- 容易误判的：HashMap 扩容时新建 table 数组、StringBuilder 扩容时 new char[]，这些才是实际触发点
用对参数，匹配你的 GC 器
-XX:PretenureSizeThreshold 只对 Serial 和 ParNew 生效；Parallel Scavenge、G1、ZGC 完全忽略它。配错等于白设：
- 用 Parallel GC（-XX:+UseParallelGC）：可设 -XX:PretenureSizeThreshold=4194304（4MB），让 ≥4MB 的对象直入老年代
- 用 G1（-XX:+UseG1GC）：不要设 PretenureSizeThreshold，改用 -XX:G1HeapRegionSize=1M（默认 2048KB），对象超过半个 region 就自动归为 Humongous Object，分配到专用 Humongous Region
- 设得过大（如 16MB）但业务最大数组才 5MB，既无效，又多一次判断开销
确保老年代能接得住，否则反而伤年轻代
满足阈值只是第一步。能否真进老年代，取决于老年代是否有足够连续空闲空间：
立即学习“Java免费学习笔记（深入）”；
- 若老年代碎片严重（如 CMS 未开启压缩），大对象分配失败，会触发 Full GC 或退化为“担保失败”，连带让 Minor GC 提前升级大量对象
- JVM 在每次 Minor GC 前做“空间分配担保”：若老年代最大连续空闲 < 当前新生代全部存活对象大小，就可能跳过 Minor GC 直接 Full GC
- 建议搭配 -XX:+PrintGCDetails 观察日志：大对象没出现在 PSYoungGen 分配记录里，却出现在 ParOldGen 使用统计中，说明已成功直入
代码层减少大对象生成，比调参更治本
参数控制的是“怎么放”，代码决定的是“要不要放”：
- 用流式处理替代全量加载：ObjectMapper.writeValue(OutputStream, obj) 替代 toJSONString()
- 分批导出：不用 list.stream().collect(toList())，改用 forEach + 分页 flush
- 复用缓冲区：ByteBuffer.allocateDirect → 改用池化（如 Netty PooledByteBufAllocator）
- 避免 static 缓存无界大对象：static Map<String, byte[]> 必须加 LRU 清理和 size 限制
