集合容量与系统负荷：分析百万级变量存入 ArrayList 导致的垃圾回收（GC）压力

先说一个核心结论：把百万级元素塞进一个 ArrayList，这事儿本身并不会直接触发 GC。但问题出在默认的扩容机制上——它会导致大约20多次的数组复制和废弃，这些操作才是真正的“幕后黑手”，会加剧 Eden 区压力、抬高 Young GC 频率，严重时甚至可能诱发 Full GC。

换言之，问题的关键不在于“存了100万条数据”，而在于“为了存这100万条数据，系统在后台默默做了多少无用功”。

扩容是怎么给 GC “添堵”的

ArrayList 的底层就是一个 Object[] 数组，初始容量只有 10。每当数组满了，也就是 size >= capacity 时，它就会调用 grow() 方法——新数组的大小大约是原来的 1.5 倍。然后通过 Arrays.copyOf()，把旧数组里的所有元素，一个个搬到新家去。

这个过程制造了两大问题：

• 每次扩容，都得从堆里重新整一块更大的连续内存（比如从 1.5MB 升到 2.25MB）。
• 扩容一完成，旧数组就彻底没人管了（变成了“不可达对象”），只能等着下一次 Young GC 来收拾它。

换句话说，往 ArrayList 里塞 100 万条数据，按默认策略大概要扩容 20 多次，也就意味着会产生 20 多个等待回收的“大件垃圾”。这些大数组全都挤在 Eden 区，很容易就把那块区域填满，逼着 GC 提前干活。这才是 Young GC 频繁触发的关键推手。

不设容量，到底有多“伤”

咱们用一个最典型的情况来看看：new ArrayList() 然后往里硬塞 100 万个 Integer 对象。

• 前几次扩容还好，影响不大。但到了后期，单次复制操作就要搬运几十万个对象，对 CPU 和内存带宽的压力直线上升。
• 大量“短命”的大数组在 Eden 区来来回回，直接导致 Young GC 的频率从原本的几秒一次，飙升到几百毫秒一次。
• 更糟糕的是，部分来不及回收的大数组可能因为 Survivor 区装不下，被“提前晋升”到老年代。这就是所谓的内存提前晋升（Premature Promotion）。
• 一旦老年代因此快速被填满，那就不得不触发代价高昂的 Full GC，造成明显的 STW（Stop-The-World）停顿。这才是问题的症结所在。

预设容量，到底能改善多少

咱们的目标不是“完全避免 GC”，而是“让 GC 的次数更少、负担更轻、行为更可预测”。

• 方法一：构造时指定容量 —— new ArrayList(1_000_000)。一上来就把最够大的房子盖好了，整个生命周期里一次扩容都不需要，只会产生一个活跃数组，Eden 区的压力降到了最低。
• 方法二：运行时预声明 —— list.ensureCapacity(1_000_000)。效果和构造时指定容量完全一样，特别适合那种没法一开始就确定最终大小，但后续有明确批量写入需求的场景。
• 实测数据很直观：用 ensureCapacity 优化后，Young GC 次数能下降 80% 以上，平均 GC 耗时减少 60%，Full GC 几乎从日志里消失了。

稳住内存水平，还需要什么

即便优化了 ArrayList 的使用方式，如果业务场景里持续有百万级的数据写入，还是建议同步把基础的内存策略也调一调：

• 堆大小设固定值：比如 -Xms4g -Xmx4g，可以避免 JVM 在运行过程中因为堆动态扩展而产生的额外开销。
• 选对垃圾收集器：推荐 -XX:+UseZGC 或 -XX:+UseG1GC，这两种收集器对突发性的大对象分配场景特别友好，延迟表现也更好。
• 用数据来验证：跑完业务后，用 jstat -gc 1s 盯一下 YGC 次数、GCT（GC 总耗时）和 EU（Eden 使用量）这几个关键指标，看看它们是不是真的明显回落了。心里有数，调优才有方向。