callable需通过executorservice.submit()提交，call()不可抛受检异常、避免阻塞操作；future.get()须设超时，禁用无参版；单线程池易致串行阻塞；completablefuture提供链式处理与聚合能力，但阻塞任务需指定线程池。
Callable 接口怎么写才不会被 Future.get() 卡死
直接用 Callable 配合 Future 拿结果，最常见问题是线程没真正提交、或 get() 被阻塞到超时甚至永久等待。关键不是接口怎么定义，而是任务是否真被线程池调度执行了。
必须确保：Callable 实例是通过 ExecutorService.submit() 提交的，而不是手动 new Thread 启动——后者返回的 Future 不可被正常管理，get() 可能永远不返回。
-
Callable的call()方法不能抛出受检异常（如IOException），只能抛Exception或其子类；否则编译不过 - 若
call()内部发生未捕获异常，Future.get()会包装成ExecutionException抛出，需显式处理 - 避免在
call()中做无限循环或阻塞 I/O（如无超时的Socket.read()），否则Future.cancel(true)可能无效
Future.get() 的三种调用方式和对应风险
Future.get() 看似简单，但不带参数的重载最危险：它会一直等，直到任务完成。生产环境几乎不该用无参版。
-
future.get()：无限等待，一旦任务卡住（比如数据库连接池耗尽、远程服务失联），整个调用线程就挂起 -
future.get(3, TimeUnit.SECONDS)：推荐用法，设超时；超时后抛TimeoutException，可及时降级或重试 -
future.get(0, TimeUnit.MILLISECONDS)：非阻塞轮询，返回前检查任务是否完成；但频繁调用浪费 CPU，适合配合isDone()做轻量轮询
注意：即使调用了 future.cancel(true)，如果 call() 方法里没响应中断（比如没检查 Thread.interrupted() 或没把中断传给底层阻塞操作），线程仍可能继续跑。
为什么 Executors.newFixedThreadPool(1) 容易让 Future 串行阻塞
单线程池本身没问题，但很多人误以为“只提交一个任务就不会影响其他逻辑”，其实只要这个任务没结束，后续所有 submit() 都会排队，连带它们的 Future.get() 全部卡住——哪怕你只是想并发查两个无关的缓存。
- 线程池大小要匹配实际并发需求，别为了“省资源”硬设为 1
- 若必须限制并发数，优先用信号量（
Semaphore）控制入口，而不是靠线程池大小隐式限流 - 对 IO 密集型任务（如 HTTP 请求），建议用
Executors.newCachedThreadPool()或自定义带合理 core/max 的线程池，避免线程饥饿
CompletableFuture 替代 Future 的真实收益在哪
如果你还在手写 Future.get() + try-catch + 超时逻辑，说明你已经踩进回调地狱边缘了。原生 Future 缺少组合能力，而 CompletableFuture 是为解决这个问题设计的。
-
thenApply()/thenAccept()可以链式处理结果，不用手动get() -
completeExceptionally()和exceptionally()让错误处理更直观，不用层层 try-catchExecutionException -
anyOf()/allOf()支持多任务聚合，原生Future做不到
不过要注意：CompletableFuture 默认使用 ForkJoinPool.commonPool()，如果任务含阻塞 IO，得显式指定线程池，否则可能拖垮整个公共池。
