只有明确后续会add大量元素且远超初始容量时调用ensurecapacity()才有意义，它只扩容底层数组不改变size，与构造函数指定容量等价但适用场景不同，需避免负数、过度预留及误以为可直接set。
什么时候该调用 ensureCapacity() 才有意义
只有在你**明确知道后续会 add 大量元素**，且这些元素数量远超初始容量时，调用 ensureCapacity() 才有实际收益。比如从数据库查出 10 万条记录后逐个 add() 到空 ArrayList，默认扩容策略（1.5 倍）会导致约 17 次数组复制；而提前 ensureCapacity(100000) 可避免所有中间扩容。
反例：循环中每次只 add 1–2 个元素、或总数不到 100，调用它反而多一次方法调用开销，无实质帮助。
ensureCapacity() 不会改变 size，只影响内部数组长度
这是最容易误解的点：ensureCapacity() 只确保底层数组（elementData）长度 ≥ 指定值，**不会修改 size，也不会填充任何元素**。调用后 list.size() 仍是 0，list.get(0) 仍抛 IndexOutOfBoundsException。
常见误用场景：
- 以为调用
ensureCapacity(100)后就能直接set(0, x)—— 实际不行，必须先add()或add(null)占位 - 和
Arrays.fill()混淆，试图“初始化”元素 —— 它只分配内存，不初始化内容
与构造函数指定初始容量的区别和选择
两种方式本质等价，但时机不同：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
-
new ArrayList(100000)：在创建时就分配数组，适合「创建即知大小」的场景 -
list.ensureCapacity(100000)：适用于已有实例、但后续要批量写入，比如作为方法参数传入后动态扩容
注意：如果已知大小，优先用构造函数 —— 少一次方法分派，语义更清晰；ensureCapacity() 更适合「延迟确定容量」的逻辑分支中使用。
性能上无本质差异，但构造函数能避免首次 add() 触发的隐式扩容判断（哪怕容量刚好匹配）。
小心负数和极小值参数导致的异常或无效行为
ensureCapacity() 对参数不做校验：传负数不会报错，但会被忽略（JDK 8+ 中内部转为 Math.max(0, minCapacity)）；传 0 或 1 通常也无意义，因为默认初始容量是 10，除非你之前调过 trimToSize() 把容量压到更低。
真正需警惕的是「过度预留」：比如预设容量 1000 万但最终只存 100 个元素，浪费堆内存，还可能触发更早的 GC。建议预留值 ≤ 预估最大 size × 1.1，而非拍脑袋放大 10 倍。
另外，多线程环境下不能靠它保证线程安全 —— 它不加锁，也不影响后续 add() 的并发行为。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
