Collections.disjoint采用短路逻辑遍历小集合并调用大集合的contains，不构造中间交集，最坏时间复杂度O(m×n)，但平均优于先求交集再判空；要求集合非null，支持不可变集合；使用前需判空，性能敏感场景下通常无需替换，底层实现比方法选择更重要。
为什么 Collections.disjoint 不是简单的“先求交集再判空”
它根本不会构造中间交集集合，而是用短路逻辑：遍历小集合，对每个元素调用大集合的 contains，一旦命中就立刻返回 false。所以时间复杂度最坏是 O(m×n)，但平均远好于先算交集再判空。
实操建议：
- 确保至少一个集合实现了高效
contains（比如HashSet是 O(1)，ArrayList是 O(n)） - 如果两个都是
ArrayList，且大小悬殊，手动把小的那个放前面传入——Collections.disjoint(smallList, bigList)比反过来快得多 - 别在循环里反复调用它判断同一组集合；如果要多次比对，提前转成
HashSet自己写短路逻辑更可控
Collections.disjoint 在 null 或不可变集合下的行为
它不接受 null 集合引用，一传进去就抛 NullPointerException；也不关心集合是否不可变，只调用 contains，所以 ImmutableSet、unmodifiableSet 都能正常用。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "java.util.Collection.contains(Object)" because "c1" is null- 误以为空集合和
null等价，结果没做判空就直接传参
使用场景中必须加一层防御：
if (setA == null || setB == null) {
throw new IllegalArgumentException("Collections must not be null");
}
boolean noOverlap = Collections.disjoint(setA, setB);
替代方案：自己写短路判断时要注意的坑
很多人想绕过 Collections.disjoint 自己实现，结果掉进性能或语义陷阱。
容易踩的坑：
- 用
retainAll判断交集：会修改原集合，且一定遍历全部元素，无法短路 - 用
stream().anyMatch(setB::contains)：语法简洁，但若setB是ArrayList，每次contains都是 O(n)，整体退化成 O(m×n)，和disjoint一样慢，但少了它内部对集合大小的自动优化 - 忽略
equals/hashCode一致性：如果集合元素没正确定义这两个方法，contains可能失效，disjoint也会错判
性能敏感场景下要不要替换 Collections.disjoint
绝大多数情况不用换。JDK 的实现已经做了小集合优先、避免迭代器创建等优化。只有当你的集合类型特殊（比如自定义的稀疏位图集合），或者你知道交集极大概率存在且总在开头几个元素里出现，才值得自己写针对性逻辑。
实操建议：
- 先用 JMH 做基准测试，别凭感觉优化
- 如果真要手写，优先复用
Collections.disjoint的思路：选 size 小的集合遍历，用Iterator而非增强 for 循环（避免额外对象创建） - 别为了省几纳秒去魔改，除非你在高频实时匹配系统里每毫秒调用上百次
真正容易被忽略的是：集合的底层实现比函数名重要得多。传两个 TreeSet 进去，contains 是 O(log n)，但如果你本意是做整数范围重叠判断，其实该用区间树或 LongBitSet ——这时候纠结 disjoint 怎么调，方向就错了。
