removeIf删除的是满足Lambda中predicate条件的元素；常见错误是混淆保留逻辑与删除逻辑，如误将u.getAge()>=18当作保留条件直接传入，导致全删或不删；需注意null安全、无并发修改及避免复杂操作。
removeIf 方法到底删的是谁？
removeIf 不是“筛选出符合条件的元素”，而是“删除所有满足条件的元素”。这点反直觉，但必须先厘清——Lambda 里写的 predicate 是“要被删掉的判断逻辑”。
比如你想保留年龄 ≥ 18 的用户，就得写成：users.removeIf(u -> u.getAge() ，而不是 <code>u -> u.getAge() >= 18。
常见错误现象：
- 调用后列表空了——很可能把保留逻辑当成了删除逻辑
- 什么都没删——Lambda 返回
false恒成立，或字段为null导致 NPE
Lambda 里访问 null 字段会直接抛异常
removeIf 内部遍历并立即执行 Predicate，一旦 Lambda 中触发 NullPointerException（如 u.getName().length() > 0 但 u.getName() 为 null），整个操作中断，已处理的部分不会回滚。
安全写法建议：
- 用
Objects.nonNull(u.getName())替代直接调用方法 - 或提前过滤：先
stream().filter(Objects::nonNull).collect(...)，再对干净集合调用removeIf - 避免在 Lambda 中做复杂计算或 IO，它本就不是为此设计的
并发修改时抛 ConcurrentModificationException 怎么办
removeIf 是在原集合上就地修改，如果另一个线程（或当前线程其他位置）正在遍历该 ArrayList（比如用 for-each 或 iterator().next()），就会触发 ConcurrentModificationException。
这不是线程安全问题，而是 fail-fast 机制在报错。解决方式只有两种：
- 加锁同步：用
synchronized(list)包住removeIf和所有遍历操作 - 改用线程安全容器：如
CopyOnWriteArrayList，但它在写多场景下性能极差，慎选
注意：removeIf 本身不保证原子性，多个条件组合时（如“删 age
性能比手写 for 循环好在哪？
removeIf 底层用的是批量移动 + System.arraycopy，比边遍历边 remove(int index) 快得多——后者每次删除都要把后续所有元素前移，时间复杂度 O(n²)。
但要注意：
- 它仍需遍历全部元素，无法短路；想提前退出得自己写循环 + break
- 返回值是
boolean（是否发生过删除），不是删了多少个，别指望靠它计数 - 如果只是临时过滤、不修改原集合，用
stream().filter(...).collect(...)更语义清晰
真正省心的地方在于：不用手动管理索引、不用担心 IndexOutOfBoundsException、也不用反复调用 size() 判断边界——这些细节它都封好了。
