invokeAll 阻塞直到所有任务完成或超时，返回已完成状态的 Future 列表；若被中断则抛 InterruptedException，未完成任务需手动 cancel(true)。
invokeAll 会等所有任务完成，但别忘了它可能抛出 InterruptedException
当你调用 invokeAll 提交一批 Callable，线程池会并发执行它们，并**阻塞直到全部结束或超时**。它返回的是 List<future>></future>，每个 Future 都已处于完成状态（成功、异常或被取消）。
常见错误是忽略中断处理：如果主线程在 invokeAll 阻塞期间被中断，它会立即抛出 InterruptedException，且**已提交但未完成的任务不会自动取消**——你得自己遍历 Future 调用 cancel(true)。
- 超时版本
invokeAll(Collection extends Callable<t>>, long, TimeUnit)</t>更安全，建议优先用 - 即使某个
Callable抛异常，invokeAll仍会等其他任务跑完，不会提前退出 - 返回的
Future调用get()不会阻塞，但可能抛出ExecutionException（包装原始异常）
List<Future<String>> futures = executor.invokeAll(tasks, 5, TimeUnit.SECONDS);
for (Future<String> f : futures) {
try {
String result = f.get(); // 此处不阻塞，但可能抛 ExecutionException
} catch (ExecutionException e) {
// 处理该任务内部抛出的异常
}
}
invokeAny 只要一个成功就返回，但失败任务仍在后台跑
invokeAny 的核心语义是“抢答”：它提交多个 Callable，**任意一个成功返回值，就立刻返回该结果**，其余任务不会被取消，继续在池中运行（除非你显式干预）。
这容易引发资源泄漏或意料外副作用。比如你用它做接口降级，但失败的 HTTP 请求仍在发包；或者任务含文件写入，多个并发写同一路径可能冲突。
- 超时版
invokeAny(Collection, timeout, unit)更常用，超时后抛TimeoutException - 如果所有任务都抛异常或被取消，
invokeAny抛ExecutionException，且getCause()是最后一个失败任务的异常 - 它不保证返回的是“最快”的结果，只保证是“第一个完成且没异常”的结果
try {
String result = executor.invokeAny(tasks, 3, TimeUnit.SECONDS);
System.out.println("拿到结果：" + result);
} catch (TimeoutException e) {
// 所有任务在 3 秒内都没完成（或都失败）
} catch (ExecutionException e) {
// 所有任务都失败了，e.getCause() 是最后一个失败任务的异常
}
invokeAll 和 invokeAny 都不支持取消已提交但未开始的任务
线程池的 submit、invokeAll、invokeAny 提交任务后，一旦进入工作队列（比如 LinkedBlockingQueue），就无法通过池本身取消——remove() 对正在运行或已排队的任务无效，且不是原子操作。
这意味着：你调用 invokeAll 后发现超时想撤回，或者 invokeAny 返回后想停掉其他还在跑的任务，必须靠 Future.cancel(true) 逐个处理，而且效果取决于任务是否响应中断。
- 任务里没检查
Thread.interrupted()或没把InterruptedException向上抛，cancel(true)就只是设个标志位，不起作用 - IO 密集型任务（如网络请求）通常响应中断较好；CPU 密集型任务若没主动轮询中断状态，基本不可取消
- 别依赖
shutdownNow()清理——它只对正在运行的任务发中断，对队列里的任务只是remove并返回，不保证取消
批量任务用哪个？看你要的是“全量结果”还是“首个可用结果”
这不是性能选择题，而是语义选择题：invokeAll 表达“我需要每项任务的结果”，invokeAny 表达“我只需要一个能用的结果”。选错会导致逻辑错误，而不是慢一点。
- 做数据聚合、校验多源一致性、生成报告 → 用
invokeAll - 做服务降级、主备切换、竞速查询（如 DNS 解析、多 CDN 获取资源） → 用
invokeAny - 如果任务本身耗时差异大，且你只关心最快那个，
invokeAny节省等待时间；但别指望它帮你“自动清理慢任务”
真正难的从来不是调哪个方法，而是想清楚：这个任务列表里，失败是不是可接受的？其他任务要不要停？结果要不要合并？这些决定了你怎么封装、怎么兜底、怎么监控。
