Callable比Runnable更适合需返回值的并发任务，因其call()方法可返回泛型结果并抛出异常，配合Future才能安全获取结果；但需注意线程安全、阻塞风险及不能直接用于Thread构造器。
Callable 为什么比 Runnable 更适合需要返回值的并发任务
Runnable 接口的 run() 方法没有返回值、也不能抛出受检异常，这在需要异步计算结果（比如远程调用、缓存预热、批量数据处理）时非常受限。Callable 的 call() 方法能返回泛型结果、且允许抛出 Exception，天然适配「启动任务 → 等待结果 → 处理返回值」这一闭环。
关键不是“能不能写返回值”，而是 JVM 和线程池如何把那个返回值安全地传出来——Runnable 做不到这点，Callable 配合 Future 才能做到。
必须搭配 Future 才能拿到 Callable 的返回值
直接 new Thread(new MyCallable()).start() 是没用的：call() 的返回值会丢失。真正起作用的是线程池的 submit() 方法，它返回一个 Future 实例：
ExecutorService pool = Executors.newFixedThreadPool(2);
Future<String> future = pool.submit(() -> {
Thread.sleep(1000);
return "done";
});
String result = future.get(); // 阻塞直到完成
注意：future.get() 是阻塞的，超时重试、取消任务、异常传播都靠它控制；如果不用 Future，Callable 和 Runnable 没本质区别。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
Future.isDone()可轮询状态，但别空转轮询，优先考虑get(long, TimeUnit) -
Future.cancel(true)可中断正在执行的线程，但前提是任务本身响应中断（检查Thread.interrupted()） - 如果
call()抛异常，get()会包装成ExecutionException再抛出
Callable 在 ExecutorService 中的实际使用约束
虽然 Callable 解决了返回值问题，但它不是“万能补丁”：
- 不能直接用于
Thread构造器，只能通过ExecutorService.submit()提交 - 无法像
CompletableFuture那样链式编排、组合多个异步任务 - 返回值类型由泛型决定，但
Future.get()仍需手动处理超时和中断逻辑 - 大量使用
future.get()容易导致线程阻塞，压垮线程池，尤其在 Web 应用中要格外小心
简单场景用 Callable + Future 足够；复杂流程建议升级到 CompletableFuture 或反应式框架。
常见错误：误以为 Callable 能绕过线程安全问题
Callable 只负责“怎么产生返回值”，不负责“返回值是否线程安全”。比如下面这段代码是危险的：
ArrayList<String> list = new ArrayList<>();
Callable<Void> task = () -> {
list.add("item"); // 多个 Callable 并发修改同一 list
return null;
};
即使每个 call() 都返回值，共享变量 list 依然可能引发 ConcurrentModificationException 或数据丢失。该加锁加锁，该换 CopyOnWriteArrayList 就换，Callable 不改变并发本质。
最常被忽略的一点：Callable 本身不解决资源竞争，它只是让「有结果的任务」能被统一调度和取回——至于结果怎么来、中间状态怎么保护，还得靠开发者自己兜底。
