collections.frequency在list和set上均为o(n)，但语义与适用性不同：list统计频次合理，set中结果仅0或1，应改用contains()；高频或多元素查询需预建map提升效率。
Collections.frequency 在 List 和 Set 上的执行效率差异，核心不在“能不能用”，而在于“为什么都得遍历”。它对两者都是 O(n) 时间复杂度，但背后的逻辑和实际影响完全不同。
底层机制：只靠 equals，不走哈希或二分
该方法内部就是朴素遍历：逐个调用 Objects.equals(element, target) 判断是否匹配。它不调用 Set.contains()，也不利用 TreeSet 的有序结构，更不会触发 HashMap 的哈希查找路径——哪怕你传的是 HashSet，它也老老实实从头扫到尾。
- List（如 ArrayList）：遍历是预期行为，O(n) 合理且直观
- HashSet：虽然底层是哈希表、单次
contains()是 O(1)，但frequency()完全绕过这个优势，仍为 O(n) - TreeSet：同样被降级为线性扫描，无法利用红黑树的 log(n) 查找能力
List 上用起来顺理成章
因为 List 本就允许重复，统计频次是典型需求。例如统计词频、日志中错误码出现次数等场景，直接传 ArrayList 或 LinkedList，语义清晰、性能可预期。
- 适合中小规模数据（几千以内），代码简洁无额外开销
- 无需预构建映射，临时查一次很轻量
- 支持
null元素统计（只要集合本身不为 null）
Set 上用容易产生误解
Set 的设计目标是去重，元素最多出现一次。所以 Collections.frequency(set, x) 的结果只能是 0 或 1 —— 这不是性能问题，而是语义冗余。
- 若你真正想问“x 是否在 Set 中”，该用
set.contains(x)，O(1) 或 O(log n)，远快于frequency() - 若你误以为传 HashSet 能加速频次统计，反而浪费了它的核心优势
- 唯一合理使用场景：调试时快速验证某个元素是否存在于 Set（但仍是杀鸡用牛刀）
真正影响效率的关键其实是数据规模和查询频率
当需要多次查不同元素的频次，或者集合很大（比如上万条），frequency() 的 O(n) 就会成为瓶颈。这时应换策略：
- 对 List：一次性用
Stream.groupingBy()或手动遍历建Map<t integer></t>，后续查 O(1) - 对原始数据源：如果频次统计是刚需，初始就用
Map存储（键=元素，值=计数），避免反复扫描 - 别为了“用了 Set”就硬套
frequency()；用途不匹配时，结构再快也没用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
