copyonwritearraylist 的 addall 方法只进行一次数组复制，而非逐个 add 的 n 次复制；它先计算新容量，一次性创建并复制数组，再批量写入，时间复杂度为 o(n+m)，显著优于逐个 add 的 o(n²)。
CopyOnWriteArrayList 在批量 addAll 时确实只做一次数组复制，而不是每加一个元素复制一次 —— 这是它区别于逐个 add 的关键优化点。
addAll 的底层实现只触发一次 copy
CopyOnWriteArrayList 的 addAll 方法内部会先计算扩容后所需的新数组长度（原 size + 集合大小），然后一次性创建新数组、拷贝原数组内容、再批量写入新增元素。整个过程只调用一次 Arrays.copyOf 或等效的数组复制逻辑，避免了 N 次 add 带来的 N 次复制开销。
- 源码中实际调用的是 copyOf + System.arraycopy 组合，不是循环调用 add
- 即使传入的集合有 1000 个元素，也仅分配并复制一次新数组
- 该行为在 JDK 8 及后续版本中保持一致
对比逐个 add：性能差距显著
如果用 for 循环对 CopyOnWriteArrayList 调用 1000 次 add，每次都会触发一次数组复制（即 1000 次 new + copy），时间复杂度 O(N²)；而 addAll 是 O(N + M)，其中 N 是原数组长度，M 是待添加元素数。
- 假设原数组长 100，添加 1000 元素：逐个 add 最坏需复制约 100×1000/2 次元素；addAll 只复制一次 1100 长度数组
- 尤其在高并发读多写少场景下，频繁写操作会严重拖慢写线程，addAll 是必须采用的写法
注意：addAll 仍是锁 + copy 的原子操作
虽然只 copy 一次，但整个 addAll 过程仍持有独占锁（ReentrantLock），且不可中断。这意味着：
- 期间所有读操作仍能并发进行（读不加锁）
- 其他写操作（如另一个 addAll 或 set）会被阻塞，直到当前完成
- 若传入集合极大（如百万级），可能导致写线程长时间持锁，影响响应性
适用边界与建议
CopyOnWriteArrayList 的 addAll 适合中小规模批量写入（通常建议单次不超过数万元素）。超大集合建议拆分或换用其他并发结构（如 ConcurrentHashMap + 定制逻辑）。
- 确认传入集合已加载完成，避免在 addAll 内部迭代时发生结构性修改（会抛 ConcurrentModificationException）
- 若需更高吞吐写入，可考虑分段批量 + 合理预估容量（通过构造函数指定初始容量减少 resize）
- 不要误以为“批量就一定快”——如果读操作极其频繁且写极少，CopyOnWriteArrayList 仍是合理选择；反之，写密集场景应避开它
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
