大对象直接进入老年代是为避免新生代复制开销，通过-XX:PretenureSizeThreshold设置阈值（如1–4MB），超过该值的对象跳过Eden区、直接在老年代分配；G1中默认阈值为Region大小的一半，超限即触发Humongous allocation。
频繁申请大对象是引发内存抖动最直接、最常见的原因之一。它不单增加 GC 压力，更会打破 JVM 对内存区域的合理分配节奏，导致 YGC 频率异常升高、Mixed GC 提前触发，甚至诱发 Full GC，最终表现为吞吐量断崖式下降和响应延迟抖动。
大对象如何绕过年轻代直接进入老年代
在 G1 中，当一个对象大小超过 -XX:PretenureSizeThreshold（默认为 Region 大小的一半）时，JVM 会跳过 Eden 区，直接在老年代中分配。这意味着： - 每次 new 一个 2MB 的 byte[]（假设 Region=4MB），就立刻占用老年代一块连续空间； - 若每秒创建 50 个这样的对象，老年代每秒净增 100MB，远超 Mixed GC 的回收能力； - 老年代快速填满，触发并发标记提前，继而频繁 Mixed GC，甚至退化为 Full GC。
典型场景与定位线索
以下现象高度提示大对象问题： - GC 日志中出现大量 “Humongous allocation” 记录； - Young GC 后老年代使用量不降反升； - Full GC 频率高但老年代回收量极低（说明不是内存泄漏，而是持续灌入新大对象）； - 数据库监控显示某接口调用后网络 IO 突增，且返回结果集 size 异常（如单次查出 50 万条记录）； - 堆 dump 中 [B（byte[]）、char[]、String、ArrayList 等基础类型实例数量少但总占比极高。
G1 下针对性优化手段
核心思路是“拦在前面、控在中间、收在后面”：
- 前置拦截：加参数 -XX:PretenureSizeThreshold=1048576（1MB），让中等对象仍走年轻代路径，避免过早污染老年代；
- 区域控制：增大 -XX:G1HeapRegionSize（如设为 2M 或 4M），减少 Humongous Region 数量，缓解碎片压力；
- 分配缓冲强化：调大 -XX:G1HeapWastePercent（如从默认 5% → 10%），避免因少量可回收空间就频繁 Mixed GC；
- 代码层兜底：对已知的大结果集操作（如报表导出、批量查询），改用流式处理（ResultSet#next() + 分页/分批）、或启用游标（cursor），杜绝一次性加载全量数据到内存。
为什么不能只靠堆扩容解决
单纯加大 -Xmx 只是延缓问题，反而可能恶化： - Region 总数变多，RSet 维护开销上升，YGC 时间拉长； - 更大的堆使 Full GC 耗时呈非线性增长（可能从 800ms → 2.3s）； - 大对象持续涌入，老年代最终仍会饱和，抖动只是推迟而非消失； - 吞吐量下降本质是无效内存搬运增多，扩容无法降低 GC 工作量，只会稀释单位时间内的回收效率。
