合理设置集合初始化容量需匹配jvm内存分代机制与实际数据规模：arraylist用new arraylist(n)避免扩容，hashmap按initialcapacity = ceil(expectedsize / loadfactor)取最近2的幂，linkedlist无需设置；动态场景可用ensurecapacity兜底；需协同-xmn、-xx:+useg1gc等jvm参数优化。
合理设置集合初始化容量，确实能降低垃圾回收压力，但关键在于“合理”——不是越大越好，也不是越准越优，而是要匹配 JVM 内存分代机制与实际数据规模。
理解扩容与 GC 的真实关系
ArrayList、HashMap 等集合底层用数组实现，扩容时需分配新数组并复制旧数据。频繁扩容会产生大量短期存活的废弃数组，加重年轻代（Young Gen）压力，触发更频繁的 Minor GC。但若初始化容量过大，又可能： - 超过 JVM 大对象阈值（如 G1 的 Region 大小或 CMS 的 PromoteThreshold），直接进入老年代； - 占用过多连续内存，加剧老年代碎片，提高 Full GC 风险； - 一次性申请大块内存，增加 GC 暂停时间（尤其在 Parallel 或 Serial 收集器下）。
按场景估算并设置初始容量
不靠猜测，而用可推导的数值：
-
ArrayList：已知将添加 n 个元素，直接用
new ArrayList(n)。它内部数组初始长度即为 n，完全避免扩容。 -
HashMap：按公式
initialCapacity = (int) Math.ceil(expectedSize / loadFactor)计算，再向上取最近的 2 的幂。例如存 100 万条，负载因子 0.75 →ceil(1000000 / 0.75) = 1333334→ 取 221 = 2097152。 - LinkedList 不适用此优化：它基于节点链表，无数组扩容问题，初始化容量参数无效，勿强行设置。
用 ensureCapacity 提前兜底
当元素数量无法精确预估，但有明确上限时，可在创建后立即调用 ensureCapacity()：
- 比构造时设容量更灵活，适用于动态构建但总量可控的场景（如解析固定格式文件，最多含 5 万行）；
- 只触发一次扩容（如有必要），把复制开销集中到初始化阶段，避免循环中多次触发；
- 示例：
list.ensureCapacity(50000);后再逐条 add，比默认构造快 2–3 倍（实测 10 万元素场景）。
配合 JVM 参数做协同优化
单靠集合调优不够，需与 GC 策略联动：
- 对高频创建大集合的应用，适当调大新生代（
-Xmn）或使用 G1 的自适应年轻代（-XX:+UseG1GC默认启用）； - 若观察到大量大对象直接进老年代，检查
-XX:PretenureSizeThreshold（G1 中由 Region 大小隐式决定），避免误判； - 启用压缩指针（
-XX:+UseCompressedOops）可减小对象头和引用体积，间接缓解数组内存压力。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
