Future.get()会阻塞当前线程直至任务完成、失败或被取消，需用try-catch处理InterruptedException、ExecutionException和CancellationException；带超时版本更安全但不自动取消任务，且不应在CompletableFuture或协程中滥用。
Future.get() 会阻塞当前线程直到任务完成
调用 Future.get() 的那一刻，当前线程就会停下来等，直到对应异步任务执行完毕并返回结果，或者抛出异常。这不是“轮询”或“回调”，而是真·阻塞等待。如果你在主线程或 Web 请求线程里直接调用它，且任务耗时长，整个线程就卡住了。
- 任务已结束：立刻返回结果
- 任务还在运行：线程挂起，不消耗 CPU，但占用线程资源
- 任务执行失败：抛出
ExecutionException，原始异常被包在里面 - 任务被取消：抛出
CancellationException
必须配合 try-catch 处理三种典型异常
Future.get() 声明抛出两个受检异常：InterruptedException 和 ExecutionException，实际使用中还常遇到 CancellationException（运行时异常）。漏掉任一处理，程序可能崩溃或静默吞错。
-
InterruptedException：当前线程在等待时被中断（比如线程池 shutdownNow），需重置中断状态或按业务逻辑响应 -
ExecutionException：任务内部抛了异常，e.getCause()才是原始错误，比如NullPointerException或IOException -
CancellationException：任务还没跑完就被cancel(true)强制终止，不能忽略——它意味着你拿不到结果，得走降级逻辑
示例片段：
try {
String result = future.get();
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
} catch (ExecutionException e) {
Throwable cause = e.getCause();
log.error("task failed", cause);
} catch (CancellationException e) {
log.warn("task was cancelled");
}
带超时的 get(timeout, unit) 更安全，但 timeout 本身也是坑
无参 get() 可能无限等下去；用带超时的版本是常规做法，但要注意：超时后 Future 对象本身**不会自动取消任务**，只是当前线程不再等了。任务仍在后台线程里跑，可能继续占用资源、写脏数据或发重复请求。
- 超时单位别写错：
TimeUnit.SECONDS和TimeUnit.MILLISECONDS差 1000 倍，常见低级失误 - 超时后建议显式调用
future.cancel(true)尝试中断任务（前提是任务代码响应中断） - 某些任务无法被中断（比如阻塞 IO、死循环没检查
Thread.interrupted()），cancel 无效，得靠业务层设计可中断逻辑
不要在 CompletableFuture 或协程环境里硬套 Future.get
如果你用的是 CompletableFuture，它提供了非阻塞的 thenApply、exceptionally 等链式方法；如果用 Kotlin 协程或 Java Virtual Threads，get() 的阻塞特性反而破坏了异步优势，白白浪费轻量级线程资源。
-
CompletableFuture场景下，优先用join()（不抛受检异常）或组合式 API，而非get() - Virtual Thread（Project Loom）中调用
get()虽不会压垮线程数，但依然阻塞该 virtual thread，失去“异步编排”意义 - 真正需要同步取结果的场景其实不多：测试验证、简单脚本、或极少数必须串行依赖的步骤
最常被忽略的一点：Future 对象本身不保证任务是否启动，也不反映中间状态；isDone() 返回 true 只代表“已结束”（成功/失败/取消），不代表“有结果”。而 get() 是唯一能拿到结果或确认失败原因的入口——所以别绕开它去猜，但也别滥用它去“等”。
