Future.get() 必须配合超时使用，裸调会无限阻塞；需捕获TimeoutException和ExecutionException；isDone()不保证结果可用；优先使用CompletableFuture；线程池关闭需配合awaitTermination。
Future.get() 会阻塞，必须配合超时使用
调用 Future.get() 不加参数是无限等待的，一旦任务卡住或抛异常未捕获，线程就彻底挂起。生产环境绝对不能裸用 get()。
- 始终用带超时的重载：
get(long timeout, TimeUnit unit)，比如future.get(3, TimeUnit.SECONDS) - 超时后要显式处理
TimeoutException，否则异常会向上冒泡中断调用链 - 如果任务已失败（如抛出
ExecutionException），get()会原样抛出封装后的异常，需 try-catch 并调用getCause()取原始异常
isDone() 和 isCancelled() 判断状态不等于结果就绪
isDone() 返回 true 只表示任务已结束（完成、异常、取消），不代表能安全调用 get()；isCancelled() 为 true 时再调 get() 会直接抛 CancellationException。
- 不要用
while(!future.isDone()) { Thread.sleep(10); }轮询 —— 浪费 CPU 且不精确 - 真正需要“等待完成”逻辑时，仍应走
get(timeout, unit)，它内部已做状态轮询和中断响应 - 若仅需检查是否完成且不取结果（如日志打点），可用
isDone()，但别把它当成“结果可用”的信号
CompletableFuture 比 Future 更实用，但别混用
原生 Future 接口只有 get / cancel / isDone 三个方法，无法链式处理、组合或指定回调线程。Java 8 引入的 CompletableFuture 是它的增强替代品，但二者不是父子关系 —— CompletableFuture 实现了 Future，却不能把 Future 当 CompletableFuture 用。
- 新代码优先用
CompletableFuture.supplyAsync(...)，而不是ExecutorService.submit(...)返回Future - 已有
Future实例无法直接转成CompletableFuture，只能包装：比如用CompletableFuture.completedFuture(result)或手动 new 一个并 set -
CompletableFuture的join()类似get()，但不抛受检异常，适合 lambda 链中使用
线程池关闭时 Future 可能永远无法完成
如果 ExecutorService 被 shutdown 但任务还在队列里，或正在执行的任务没响应中断，对应的 Future 就会卡在 get() 上，甚至 JVM 退出都等不到它。
立即学习“Java免费学习笔记（深入）”；
- 务必在 shutdown 后调用
awaitTermination(...)，并根据返回值判断是否还有活跃任务 - 对可能长时间运行的任务，应在业务逻辑里定期检查
Thread.interrupted()，主动退出 - 避免在 finally 块里无条件调用
future.get()—— 如果线程池已 shutdown，这里就成了死锁点
