Java groupingBy当classifier返回List时的运行机制及相关问题

1. groupingBy配合List做分类器的运行原理 #

Collectors.groupingBy()本身不会针对分类器的返回值类型做特殊逻辑判断，它的分组逻辑完全遵循Java集合框架的通用规则：用分类器返回的对象作为Map的Key，依赖Key对象自身的hashCode()和equals()方法判断两个Key是否相等，和你用String、Integer等常见类型做Key的逻辑完全一致，没有特殊处理。
你观察到的“按List元素逐一比对分组”的效果，是List接口的规范要求：所有实现了List接口的类（比如ArrayList、LinkedList），equals()方法都要求按顺序逐一比对每个位置的元素，只要两个List的元素数量、元素顺序、对应位置的元素全部相等，就判定为相等；对应的hashCode()方法也会按元素的哈希值顺序计算，相等的List一定得到相同的哈希值。所以最终呈现出来的分组效果就是按List元素匹配，不是groupingBy专门适配了List类型。

2. List存储不同类型元素的机制 #

如果声明List的时候没有指定泛型参数（也就是使用原生类型raw type），或者显式指定泛型为List<Object>，那么它的元素类型就是Object，Java中所有类都是Object的子类，所以可以存入任意类型的对象。
如果声明时指定了具体的泛型参数，比如List<String>，编译器会做编译期类型检查，不允许存入非String类型的元素，除非通过类型擦除的方式绕过检查，但这种写法会触发编译警告，运行时也可能抛出类型转换异常。

3. 用List做分组键是否属于反模式 #

是否属于反模式要结合使用场景判断：

• 如果是临时的、小范围使用的一次性聚合逻辑（比如写个临时脚本做数据统计），用List做复合分组键可以省掉专门自定义Key类、重写equals/hashCode的工作量，属于合理的便捷写法。
• 如果是生产环境的核心业务代码，或者复合键的逻辑会被多处复用，这种写法就属于典型的反模式：
  • 类型不安全：无法限制每个位置的元素类型，很容易因为传错元素位置、传错元素类型导致隐性bug，很难排查
  • 语义不清晰：其他维护者无法直观知道List第0位、第1位分别对应什么业务字段，理解成本很高
  • 性能更差：List的equals和hashCode需要遍历所有元素计算，自定义Key类可以直接对固定字段做计算，开销更小

内容的提问来源于stack exchange，提问作者IsaacLevon