为什么Collectors.toUnmodifiableList需对中间累加器做类型校验？

这个类型校验的核心作用是保证不可变列表的安全性，同时遵守公开API的防御性设计规范，不能按你说的简化，原因有三点： #

1. 你的假设只在OpenJDK内置Stream实现的场景下成立，不具备通用性

Collector是JDK公开的标准API，并非只能被内置的Stream实现调用：

• 第三方框架可以自行实现java.util.stream.Stream接口，完全可以传入非ArrayList的实例作为累加器交给finisher处理
• 开发者也可以直接获取Collector的四个函数（supplier/accumulator/combiner/finisher）自行调用，完全可以传入任意List实例到finisher中

如果没有这个类型校验，传入自定义List实现时就会出现安全问题：listFromTrustedArray方法会直接复用传入的数组创建不可变列表，不会做二次拷贝，前提是这个数组是「可信的」——也就是不会被其他对象持有并修改。ArrayList的toArray()方法会返回一个新拷贝的数组，符合可信要求；但自定义的List实现完全可以让toArray()直接返回内部数组的引用，后续修改内部数组就能间接修改所谓的「不可变列表」，直接破坏不可变承诺。

2. 替换为ArrayList::add并不能规避上述问题

就算你把累加器、合并器的方法句柄都换成ArrayList的专属实现，也阻止不了外部代码绕过标准Stream流程，直接调用finisher传入其他List实例，安全风险依然存在。而且把接口方法句柄替换为具体实现的句柄，反而会降低代码的可维护性：如果后续JDK要修改累加器的实现（比如替换为更适合收集场景的其他List实现），需要同步修改所有关联的方法句柄，远不如只改finisher的校验逻辑方便。

3. 两种异常的影响完全不同

你认为两种异常没有区别的前提是「传入非ArrayList实例一定会抛ClassCastException」，但实际不是：如果传入的自定义List实现没有类型问题，调用toArray()也能正常返回，代码不会抛任何异常，只会生成一个假的不可变列表，这是严重的安全缺陷，远比抛异常的影响大。就算真的触发异常，IllegalArgumentException也更符合语义——本质是传入的finisher参数不符合收集器的预期要求，不是单纯的类型转换错误。

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