Collections.frequency适用于单元素频次统计，语义清晰但仅支持精确equals比较；Stream.groupingBy适合全量频次统计，性能更优但需注意null键和自定义对象的equals/hashCode实现。
直接用 Collections.frequency 统计单个元素出现次数
如果只是查某个特定值在 List 里出现了几次，Collections.frequency 是最轻量、最直观的选择。它内部就是遍历比较，没魔法，但胜在语义清晰、无额外依赖。
常见错误是传入 null 元素或用错引用类型（比如用 new String("a") 去查一个池中字符串），导致结果为 0——本质是 equals 不成立。
- 只适合「查一个」，查多个就得循环调用，性能线性下降
- 对
null安全：传null作为目标时，会正确统计null元素个数 - 不支持自定义比较逻辑（比如忽略大小写、按字段比）
示例：
int count = Collections.frequency(list, "apple");
用 Stream.collect(Collectors.groupingBy) 批量统计所有元素频次
要一次性得出每个元素各出现几次，必须用分组聚合。核心是 Collectors.groupingBy 配合 Collectors.counting()，返回 Map<T, Long>。
立即学习“Java免费学习笔记（深入）”；
容易踩的坑是忘了处理 null 键：如果 List 含 null，默认分组会抛 NullPointerException。得显式允许 null 键，或提前过滤。
- 键类型必须重写
equals和hashCode，否则自定义对象会统计不准 - 返回值是
Long而非Integer，避免大集合溢出 - 性能比多次调用
Collections.frequency好得多，尤其元素种类不多时
示例：
Map<String, Long> freqMap = list.stream()<br> .collect(Collectors.groupingBy(Function.identity(), Collectors.counting()));
遇到自定义对象，别漏掉 equals/hashCode 实现
用 groupingBy 或 Collections.frequency 查自定义类实例时，如果没重写 equals 和 hashCode，哪怕字段值完全一样，也会被当成不同元素——因为默认比较的是引用地址。
典型现象：明明两个 User 对象 id 和 name 都相同，但频次统计显示各出现 1 次，而不是合并为 2 次。
- IDE 通常能自动生成这两个方法，用 Lombok 的
@EqualsAndHashCode更省事 - 如果只想按某几个字段比较（比如只看
id），就只在生成时勾选对应字段 - 千万别用
toString()或 JSON 序列化结果当分组依据，效率低且易出错
性能和内存取舍：小列表用 Collections.frequency，大列表或需全量统计时用 Stream 分组
单纯查一两次，Collections.frequency 几乎零开销；但若循环查几十个不同值，等于反复遍历整个列表，时间复杂度 O(n×m)。而 Stream 分组一次遍历搞定，O(n)，但会多占一份 Map 内存。
另一个现实约束：Android 旧版本（API < 24）不支持 Stream，这时只能手写 HashMap 累加，或者用 Collections.frequency 加缓存。
- Java 8+ 项目，优先用
Stream分组，代码更可读 - 对延迟敏感场景（如高频实时计算），注意
Stream创建和收集有轻微开销，简单 case 仍可考虑传统 for 循环 +HashMap -
Collectors.groupingByConcurrent在并发环境下有用，但普通单线程别滥用，反而拖慢
真正麻烦的不是语法，而是想清楚你要的是「查一个」还是「全量分布」——选错方式，后面补救成本远高于一开始多想两秒。
