addall最轻量但不去重；removeall和retainall性能取决于参数集合类型，hashset作参数时retainall更高效；避免循环调用及并发使用，优先预转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或漏删
HashSet，往往比花 10s 等 removeAll 慢吞吞跑完更值得。很多人卡在“方法选对了”，却忘了喂给它的数据结构才是真正的开关。 
