下界通配符提升任务兼容性实战

本文澄清了一个常见的技术误区：下界通配符（? super T）并不适用于ExecutorService.submit(Callable)场景，因为它无法满足Callable接口对确定返回类型的严格要求，而该问题本质并非泛型通配符的误用，而是类型建模不当与API误读所致；文章指出真正提升线程池任务兼容性的关键在于明确结果的公共上界类型、合理选用线程池、控制任务粒度、善用invokeAll批量提交与超时机制——把焦点从“语法技巧”拉回“设计本质”，帮你避开并发编程中隐蔽却高频的类型陷阱。

这个问题存在概念混淆，需要先厘清关键点。

下界通配符（? super T）不适用于向线程池提交 Callable 任务的场景。

原因很直接：
ExecutorService.submit() 方法接收的是具体类型的 Callable，不是泛型容器，也不涉及集合的“写入安全”问题。下界通配符主要用在泛型集合的参数化方法中（比如 Collection dest），目的是允许向集合中添加 String 或其子类实例——它解决的是“消费者”端的类型兼容问题（PECS 原则中的 Consumer）。而 submit(Callable) 是一个方法调用，要求传入一个可实例化的、具有确定类型参数的 Callable 对象，编译器必须能推断或明确 T 是什么，才能构造 Future 并支持后续 get() 的类型安全返回。

你无法写出这样的合法代码：

ExecutorService exec = Executors.newCachedThreadPool();
Callable task = () -> 42; // ❌ 编译错误：Callable 是函数式接口，call() 返回类型必须是具体类型，不能是通配符
exec.submit(task); // 这行根本过不了编译

真正可行且常用的做法是：

• 用具体父类作为 Callable 的泛型参数
  比如你有一组任务，有的返回 Integer，有的返回 BigDecimal，但都可视为 Number，那就统一用 Callable：

  Callable task1 = () -> 100;
  Callable task2 = () -> new BigDecimal("3.14");
  Future f1 = exec.submit(task1);
  Future f2 = exec.submit(task2);

• 利用类型擦除与协变返回的自然兼容性
  Callable 可赋值给 Callable 变量（因为 Integer 是 Number 子类），这是 Java 的协变特性，无需通配符：

  Callable c = (Callable) (Callable) () -> 42; // 向上转型，安全
  exec.submit(c); // ✅ 提交成功

• 若需统一处理多种返回类型，建议用 Future + 运行时类型判断
  提交时用 submit(Runnable, T result) 或直接 submit(Callable