Callable能返回结果而Runnable不能：前者call()返回泛型V并支持受检异常，后者run()返回void；Callable需通过ExecutorService.submit()配合Future获取结果，不可直接用于Thread。
Callable能返回结果，Runnable不能
这是最根本的区别。Runnable 的 run() 方法返回 void，执行完就结束了，没法带回任何计算结果；Callable 的 call() 方法返回泛型类型 V，支持抛出受检异常，天然适配需要结果的异步任务。
实际写法上：Runnable 通常直接传给 Thread 或线程池；Callable 必须配合 FutureTask 或提交到 ExecutorService 才能获取返回值。
-
Runnable：适合“只管执行、不关心结果”的场景，比如日志刷盘、心跳上报 -
Callable：适合“发起请求、等待响应”的逻辑，比如远程接口调用、数据库查询、文件解析 - 若强行让
Runnable“带结果”，只能靠外部共享变量（如AtomicReference），但需自行处理可见性和竞态，容易出错
submit() 返回 Future，get() 才真正阻塞取值
很多人以为调用 executor.submit(callable) 就会卡住主线程——其实不会。submit() 立即返回一个 Future 对象，任务只是被调度进队列，此时还没开始执行，更没返回结果。
真正触发阻塞的是 future.get()。它会一直等到任务完成（或超时/被中断），才返回 call() 的返回值。如果任务抛出异常，get() 会包装成 ExecutionException 抛出。
立即学习“Java免费学习笔记（深入）”；
ExecutorService executor = Executors.newFixedThreadPool(2);
Future<Integer> future = executor.submit(() -> {
Thread.sleep(1000);
return 42;
});
// 此时任务可能刚启动，甚至还没轮到执行
System.out.println("submitted");
<p>Integer result = future.get(); // 这里才阻塞，等待1秒后拿到42
System.out.println(result); // 输出 42Callable必须用 ExecutorService，不能直接 new Thread()
Thread 构造函数只接受 Runnable，不接受 Callable。想运行 Callable，必须走线程池的 submit() 流程，由框架内部用 FutureTask 包装一层。
有人试图这样绕过：
new Thread(() -> {
try {
Integer r = myCallable.call();
// 手动存结果……
} catch (Exception e) { /* 忽略或打印 */ }
}).start();这等于抛弃了 Future 的所有能力：无法取消、无法判断状态、无法统一异常处理、无法超时控制。本质上退化成了带返回值的 Runnable，但失去了并发工具链的支撑。
- 正确路径只有一条：用
ExecutorService.submit(Callable) - 别自己封装
Thread+Callable，那不是简化，是重复造轮子且漏关键语义 - 如果真需要轻量级带返回值，考虑
CompletableFuture.supplyAsync()，它底层也是基于Callable，但 API 更现代
get() 调用时机不当会导致线程阻塞不可控
最容易被忽略的是：Future.get() 是同步阻塞操作，如果在循环中逐个 get()，就完全失去了并发意义——变成串行等待。
例如提交 10 个耗时任务，逐个 get()，总耗时 ≈ 所有任务时间之和；而用 invokeAll() 或批量检查 isDone()，总耗时 ≈ 最长那个任务的时间。
- 避免在 for 循环里直接
future.get() - 批量任务优先用
executor.invokeAll(listOfCallables)，它会等全部完成再统一返回List<Future<V>> - 需要部分结果就返回时，用
future.isDone()+future.get(0, TimeUnit.NANOSECONDS)非阻塞轮询 - 生产环境强烈建议 always 带超时参数调用
get(long timeout, TimeUnit unit)，防止某个任务 hang 死整个流程
返回值本身不是难点，难的是把“异步提交”和“同步取值”这两个阶段拆开设计，并意识到 get() 是那个真正的性能闸门。
