Collections.frequency统计元素频次依赖equals逻辑相等，要求目标类正确重写equals（及hashCode），对null安全但时间复杂度O(n)，不支持数组和Stream，需先转为Collection。
用 Collections.frequency 统计元素次数，前提是集合支持 equals
这个方法本质是遍历 + 调用 Objects.equals(element, target)，所以它只认「逻辑相等」，不认引用或结构一致。比如两个内容相同的 ArrayList 对象，哪怕元素完全一样，Collections.frequency(list, anotherList) 也返回 0——因为默认 ArrayList.equals() 是重写的，但如果你传的是没重写 equals 的自定义类实例，结果就不可靠。
实操建议：
- 确保目标元素的类已正确重写
equals（和hashCode，虽然这里不直接用到hashCode，但逻辑一致性必须） - 对
null值安全：传null作 target 没问题，方法内部会用==判空 - 别对大集合反复调用：时间复杂度是
O(n)，查 10 个不同元素就是 10×n，不如先转成Map计数
Collections.frequency 在数组或流里不能直接用
它只接受 Collection 接口实现，比如 ArrayList、LinkedList、HashSet。传原始数组（int[]、String[]）会编译报错，因为数组不是 Collection；传 Stream 也不行，Stream 不是集合。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
Collections.frequency(new String[]{"a","b","a"}, "a")→ 编译失败：no suitable method found -
Collections.frequency(list.stream().filter(...), "a")→ 类型不匹配，Stream不是Collection
正确做法：
- 数组转集合：
Collections.frequency(Arrays.asList(arr), target)（注意：Arrays.asList对基本类型数组无效） - 流要先收集：
list.stream().filter(Objects::nonNull).collect(Collectors.toList())，再传给frequency - 原始类型数组（如
int[]）只能手写循环或用IntStream+filter+count()
替代方案：什么时候该放弃 Collections.frequency
单次查询小集合（
性能与场景权衡：
- 查一个值 1 次？用
Collections.frequency没毛病 - 查多个值？用
Map一次遍历更省：Map<string integer> counts = new HashMap(); for (String s : list) counts.merge(s, 1, Integer::sum);</string> - 并发环境？
Collections.frequency本身无状态，但若集合正在被其他线程修改，结果可能不一致——得加锁或换CopyOnWriteArrayList - 内存敏感？它不缓存，每次都是新遍历；而
HashMap计数虽占内存，但后续查O(1)
容易被忽略的边界：空集合、不可变集合、迭代器中途修改
它不会抛 NullPointerException 给空集合，但传 null 集合会炸——NullPointerException 来自方法内部对 collection.iterator() 的调用。
典型陷阱：
-
Collections.frequency(null, "x")→NullPointerException（不是IllegalArgumentException） -
Collections.frequency(Collections.emptyList(), "x")→ 安全，返回0 - 对
Collections.unmodifiableList(...)使用没问题，因为只是包装，底层仍是可遍历集合 - 在增强 for 循环里边遍历边删元素，再调用
frequency？可能触发ConcurrentModificationException，取决于具体集合实现
真正难搞的是嵌套结构里的“深层相等”——比如想统计某个 Map 在 List<Map<String, Object>> 中出现几次，你得自己实现 equals，否则默认比的是引用。
