Future.get() 必须带超时参数，否则会无限阻塞；cancel(true) 仅对可中断任务有效；CompletableFuture 回调需避免同步阻塞；异常需显式调用 get() 或 handle() 才能捕获。
Future.get() 会阻塞线程，必须配合超时使用
直接调用 Future.get() 是最常见错误：它会无限期等待任务完成，一旦后端服务响应慢或死锁，整个线程就被卡住。生产环境必须带超时参数。
-
get(long timeout, TimeUnit unit)是唯一安全用法，推荐设为业务可容忍的最长时间（如3000毫秒） - 超时抛出
TimeoutException，需显式捕获并处理降级逻辑（如返回缓存值或空结果） - 不要在主线程（如 Spring MVC 的 Controller）中无保护调用
get()，否则接口吞吐量直线下跌
try {
String result = future.get(3, TimeUnit.SECONDS);
} catch (TimeoutException e) {
// 降级处理
result = "default";
} catch (ExecutionException | InterruptedException e) {
Thread.currentThread().interrupt();
}
submit() 返回的 Future 无法取消正在运行的任务
Future.cancel(true) 只对「尚未开始执行」或「处于可中断状态」的任务生效。Java 线程本身不支持强制终止，cancel(true) 实际只是调用 Thread.interrupt()，效果取决于任务内部是否响应中断。
- 若任务里有
Thread.sleep()、BlockingQueue.take()等可中断阻塞调用，interrupt()能使其提前退出 - 纯计算型循环（如
while (flag) { ... }）必须手动检查Thread.currentThread().isInterrupted() - 数据库查询、HTTP 请求等外部调用通常不响应中断，cancel 几乎无效，需靠连接超时或客户端主动断连
CompletableFuture 比原始 Future 更实用，但别滥用 thenApply
CompletableFuture 是 Future 的增强替代，但很多开发者误以为链式调用就等于“不阻塞”——其实 thenApply 回调仍在 ForkJoinPool 线程中执行，若回调里又调用了 get() 或同步 IO，照样拖垮线程池。
- IO 密集操作（如 HTTP 调用）应改用
thenComposeAsync(..., executor)，指定专用线程池 - 避免在回调中调用
join()或get()，这会让异步变同步 -
supplyAsync默认使用ForkJoinPool.commonPool()，高并发下容易被 CPU 密集任务占满，务必传入自定义线程池
ExecutorService ioExecutor = Executors.newFixedThreadPool(10);
CompletableFuture.supplyAsync(() -> callHttp(), ioExecutor)
.thenApplyAsync(result -> parseJson(result), ioExecutor);
异常不会自动抛出，必须显式检查 get() 或 handle()
Future 执行中抛出的异常不会传播到主线程，而是被静默封装进 ExecutionException。如果只调用 isDone() 或忽略 get() 结果，异常就永远丢失。
立即学习“Java免费学习笔记（深入）”；
- 必须调用
get()（哪怕只是为了触发异常）才能拿到真实异常原因 -
CompletableFuture.handle()是更安全的选择，能同时处理正常结果和异常 - 日志中只打印
e.toString()会丢失根因，要用e.getCause().printStackTrace()或结构化日志记录e.getCause()
最容易被忽略的是：即使任务已失败，isDone() 仍返回 true，但你不调用 get() 就永远不知道它失败了。
