addAll、removeAll与retainAll性能对比分析

本文深入剖析了Java集合中addAll、removeAll与retainAll三大批量操作的性能本质，指出addAll虽轻量高效但不处理重复，而removeAll和retainAll的真实性能差异并不取决于方法本身，而是由参数集合的实现类型（尤其是是否为HashSet）决定——用HashSet作参数可将retainAll从O(m×n)优化至近O(n)，提速可达百倍；同时警示避免循环调用、并发误用及忽视参数集合结构等常见陷阱，强调“选对方法不如喂对数据结构”，预转HashSet往往是性价比最高的性能优化手段。

addAll 是最轻量的批量添加，但重复元素照单全收

如果你只是想把一批元素快速塞进现有集合，addAll() 是首选。它底层通常用 System.arraycopy 或循环调用 add()，开销小、语义直白。

• 对 ArrayList：时间复杂度接近 O(n)，前提是容量足够；否则触发扩容（复制数组），会有隐式成本
• 对 HashSet：每个元素都要算 hash、查冲突、可能再扩容，实际是 O(n) 但常数更大
• 注意：addAll() 不去重 —— 即使目标集合是 Set，传入含重复的 List，也不会自动过滤；它只负责“加”，不负责“判重”
• 别误以为 addAll() 能替代合并逻辑：它不做交/并/差判断，就是无脑追加

removeAll 和 retainAll 都会遍历+查找，但行为和性能陷阱完全不同

removeAll() 删除当前集合中「出现在参数集合里」的所有元素；retainAll() 则反向保留「只在参数集合里也存在」的元素。表面看都是“基于另一个集合做筛选”，但内部逻辑差异直接拉开了性能差距。

• removeAll() 在 ArrayList 上是 O(m×n)：对每个待删元素，都要遍历整个参数集合检查是否包含 —— 如果参数是 ArrayList 或 LinkedList，没有哈希加速，非常慢
• retainAll() 同样受参数集合类型影响：若传入的是 HashSet，查找是 O(1)，整体接近 O(n)；若传入 ArrayList，就退化成 O(m×n)
• 两者都会修改原集合，且返回 boolean 表示“是否发生了结构性变更”——这个返回值常被忽略，但它能帮你判断操作是否真正生效（比如两个集合完全不相交时，retainAll() 返回 false）
• 危险操作：list.retainAll(list) 看似无害，实则返回 false 且不报错，容易让人误以为“没执行成功”而补逻辑

效率排序不是固定的，关键看「参数集合的实现类」

别背“retainAll 比 removeAll 快”这种结论——它们快慢取决于你喂给它们什么类型的参数集合。

• 如果你要从大列表中筛出小名单里的用户，把小名单转成 HashSet 再传给 retainAll()，速度可能比 removeAll() 快一个数量级
• 反过来，如果参数集合本身是 LinkedList，又没预转哈希结构，那无论用哪个方法，性能都难看
• containsAll() 虽不修改集合，但底层也是逐个调用 contains()，同样吃参数集合的查找效率——别用它来“预检”再决定是否 retainAll，纯属多一遍遍历
• 真实项目里常见坑：日志里看到 retainAll 执行了 500ms，结果发现传进去的是个没建索引的 ArrayList，换成 HashSet 后降到 5ms

别在循环里反复调用这些批量方法

批量方法不是“魔法”，它们依然要遍历、比较、移动引用。如果在 for 循环里反复对同一个大集合调用 retainAll()，等于每次都在做一次完整扫描+重建，极易成为性能瓶颈。

• 更稳的做法：先把所有筛选条件聚合到一个 Set 里，再一次性 retainAll()
• 如果逻辑复杂（比如要按优先级分批保留），考虑改用 Stream.filter() + 收集为新集合，语义清晰且避免原集合被意外污染
• removeAll() 在并发场景下尤其危险——没加锁时，其他线程可能正在增删元素，导致 ConcurrentModificationException 或漏删

实际写的时候，花 100ms 把参数集合转成 HashSet，往往比花 10s 等 removeAll 慢吞吞跑完更值得。很多人卡在“方法选对了”，却忘了喂给它的数据结构才是真正的开关。

理论要掌握，实操不能落！以上关于《addAll、removeAll与retainAll性能对比分析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！