? super t 是为支持逆变，使收集器能安全接收 t 及其子类型元素，符合 pecs 原则中“consumer super”；它确保 accumulator 方法可接受更宽类型的输入，保障类型安全。
Java 中 Collector super T, A, R> 接口定义里的 ? super T 是为了支持**逆变（contravariance）**，让收集器能安全地处理子类型元素，同时保持类型安全。这不是语法错误或设计缺陷，而是为泛型协变/逆变机制服务的关键设计。
为什么用 ? super T 而不是 T
收集器的累积过程（accumulator）需要把流中的每个元素“加进去”，即调用类似 void accept(A container, ? super T element) 的方法。这里要求容器能接受 T 及其所有子类型 —— 也就是“写入”场景，适合用上界通配符 ? super T。
- 若写成
Collector<t a r></t>，则无法将Integer流传给期望接收Number的收集器（比如Collectors.toList()实际接受List super Integer>，允许存入Integer到List<number></number>） -
? super T允许你把T类型的元素“喂给”一个能容纳更宽类型（如父类或接口）的收集器，符合 PECS 原则（Producer Extends, Consumer Super）
自定义收集器时如何正确声明和实现
定义自己的 Collector 时，必须严格匹配 Collector super T, A, R> 的类型参数顺序，并在 supplier、accumulator、combiner、finisher 四个函数中体现 ? super T 的约束。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
supplier()：返回中间容器（如ArrayList<a></a>），与T无关，不涉及? super T -
accumulator()：签名应为(A, ? super T) -> void，例如：(list, e) -> list.add((T) e)或更安全地使用泛型方法约束 -
combiner()：合并两个中间结果，不操作T，也不受? super T影响 -
finisher()：从A构造R，同样不涉及T
常见误用与编译错误示例
错误写法往往源于忽略 ? super T 对 accumulator 输入类型的放宽要求：
- 把
BiConsumer<list>, String></list>当作 accumulator，却试图用于Stream<object></object>→ 编译失败，因为String不是Object的超类型 - 正确做法是声明 accumulator 为
BiConsumer<list>, ? super Object></list>，但实际需确保运行时类型兼容（如只添加String实例） - 自定义收集器类实现
Collector super Person, List<person>, List<person>></person></person>时，若 accumulator 写成(list, p: Student)（Student 是 Person 子类），没问题；但若反过来（expecting Student but given Person），就可能出错
实用建议：如何写出类型安全的自定义收集器
不必手动写泛型通配符，优先复用 Collector.of() 工厂方法，它会自动推导并约束类型：
- 用
Collector.of(Supplier, BiConsumer<a super t>, BinaryOperator, Function)</a>构建，编译器会检查BiConsumer是否满足? super T - 若手写类实现
Collector接口，泛型声明必须是Collector super T, A, R>，不能省略? super - 测试时用不同子类型流验证：比如用
Stream<dog></dog>和Stream<animal></animal>都能成功传入同一个Collector super Dog, ..., ...>
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
