选callable+future因runnable无返回值和异常处理能力，而callable支持泛型返回与受检异常，future提供结果获取、状态检查与超时控制；线程池须自定义配置核心/最大线程数、有界队列、命名工厂及callerruns拒绝策略；聚合需设单任务超时、分类型异常处理、空值校验，并避免submit后立即get；复杂场景应升级completablefuture以支持链式编排与响应式处理。
Java中用Callable配合Future实现微服务多接口并行聚合，核心是把原本串行的远程调用变成并发执行，让总响应时间趋近于最慢那个接口的耗时，而不是所有接口耗时之和。
为什么选Callable + Future而不是Runnable
微服务间调用必须拿到返回结果才能组装最终响应，而Runnable的run()方法没有返回值，也无法抛出受检异常。Callable的call()方法支持泛型返回值（比如JSONObject、UserDTO、BalanceVO），还能直接throw Exception，适配HTTP或RPC调用可能发生的网络超时、服务不可用等异常场景。Future则作为“结果凭证”，让主线程按需获取、检查状态或设置超时，不阻塞在无关阶段。
线程池要自定义，不能用Executors快捷工厂
微服务环境对资源敏感，共享线程池容易引发雪崩。必须显式配置：
- 核心线程数与最大线程数分离，避免突发流量打满
- 使用有界队列（如LinkedBlockingQueue(100)），防止OOM
- 指定ThreadFactory命名，便于日志追踪（如"rpc-aggregate-pool-%d"）
- 拒绝策略推荐CallerRunsPolicy：当队列满且线程达上限时，由提交任务的业务线程自己执行，起到自然限流作用
聚合逻辑要兼顾正确性与容错
多个接口并行后，并不是简单等全部返回再拼装。实际中建议：
- 对每个Future调用get(long, TimeUnit)设超时（如800ms），避免一个慢接口拖垮整体
- 捕获ExecutionException和TimeoutException，区分处理：超时可降级返回默认值，业务异常可记录告警但不中断聚合
- 结果合并前校验非空，例如userTask.get()返回null时跳过putAll，防止NPE
- 不要在submit后立刻get，可先submit全部任务，再统一get，减少等待空隙
注意Future本身的局限性
原生Future适合“提交→等结果”这种简单模型，但不支持链式编排、无法自动回调、异常处理扁平。如果后续需要做结果转换（如用户信息+余额→信用分）、失败重试、或者部分结果就可返回（比如只要用户基础信息到位就先响应），应升级到CompletableFuture。它能用thenApply、exceptionally、anyOf等方法构建响应式流程，更适合复杂聚合场景。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
