Callable 与 Runnable 的核心区别在于：Callable 的 call() 方法可返回泛型结果并抛出受检异常，而 Runnable 的 run() 方法返回 void 且不能抛受检异常；因此 Callable 配合 Future 才能实现异步结果获取。
Callable 和 Runnable 的核心区别在哪
Runnable 只能执行任务，不能返回值；Callable 则必须实现 call() 方法，且可以返回任意类型（支持泛型），还能抛出受检异常。这是异步取结果的前提——没返回值，Future 就无从“取”起。
-
Runnable的run()返回void，线程池提交后彻底失联 -
Callable的call()返回V，提交后得到Future<v></v>，才可后续获取结果 - 不要试图把
Runnable强转成Callable——编译不通过，类型不兼容
Callable<Integer> task = () -> {
Thread.sleep(1000);
return 42;
};
submit() 后怎么安全拿到结果
调用 Future.get() 是唯一出口，但它会阻塞当前线程，直到计算完成或超时。实际中必须控制阻塞行为，否则主线程卡死。
- 直接调用
future.get()：无限等待，生产环境禁用 - 推荐用
future.get(3, TimeUnit.SECONDS)设超时，避免长等待拖垮调用方 - 如果任务已取消或执行失败，
get()会抛出CancellationException或ExecutionException，必须捕获处理 -
isDone()和isCancelled()可用于轮询状态，但轮询效率低，仅适合极短周期、低频检查场景
别忘了：即使任务抛了异常，get() 也会把它包在 ExecutionException 里再抛出，原始异常在 .getCause() 中。
线程池选 Executors.newFixedThreadPool() 还是 ForkJoinPool
普通 CPU 密集型计算，用 newFixedThreadPool(n) 更可控；I/O 等待多或任务可拆分（比如递归分治），ForkJoinPool.commonPool() 才有优势。
-
newFixedThreadPool(4)：线程数固定，队列无界，适合任务耗时稳定、数量可预期的场景 -
ForkJoinPool.commonPool()：默认并行度为CPU 核数 - 1，工作窃取机制对细粒度任务友好，但Callable提交后无法保证执行顺序，且异常传播更隐晦 - 避免用
Executors.newCachedThreadPool()：最大线程数无限制，突发大量任务可能触发 OOM
如果你的任务只是“发个 HTTP 请求+解析 JSON”，别迷信 ForkJoinPool——它不擅长阻塞操作，反而容易因线程饥饿导致整体变慢。
为什么 Future.isDone() 返回 true，get() 却还阻塞
这种情况极少发生，但一旦出现，基本是以下两个原因：
- 任务本身没真正结束：比如
call()方法里用了synchronized锁住某个静态资源，另一个线程一直占着，导致任务卡在最后一步 -
Future被包装过：某些框架（如 Spring 的@Async）返回的是代理对象，其isDone()可能提前返回true，但实际结果还没写入底层Future
最稳妥的验证方式是直接看 future.get(1, TimeUnit.MILLISECONDS) 是否立即返回——如果超时，说明结果确实没就绪，别信 isDone() 的表面值。
真正麻烦的是异常发生在 call() 末尾、但未被 get() 暴露前，日志里什么痕迹都没有。这种时候，加一行 System.out.println("call done") 在 return 前，比查文档快得多。
