Future.get() 默认阻塞，需用超时重载或isDone()判断；抛出InterruptedException、ExecutionException、TimeoutException须分别处理；禁在UI/Servlet主线程调用；cancel()不保证资源清理，任务需自行响应中断。
Future.get() 会阻塞，除非你用带超时的重载或提前判断 isDone()
Future.get() 阻塞是默认行为，不是 bug
调用 get() 时，线程会一直挂起，直到任务完成或抛出异常。这在主线程中直接调用极易导致响应卡死。
- 不带参数的
get()：无限等待，无超时机制 - 带超时的
get(long timeout, TimeUnit unit)：超时后抛出TimeoutException，必须显式捕获 - 调用前可用
isDone()判断是否已完成，但无法预知何时完成，仅适合轮询场景（不推荐）
get() 抛出的三种异常必须处理
get() 声明抛出三个受检异常，每种对应不同失败路径：
-
InterruptedException：当前线程被中断（如调用Thread.interrupt()），需恢复中断状态或明确处理 -
ExecutionException：任务内部抛出异常，其getCause()才是原始异常（比如NullPointerException） -
TimeoutException：仅出现在带超时版本中，表示任务未在指定时间内结束
try {
String result = future.get(3, TimeUnit.SECONDS);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断标记
} catch (ExecutionException e) {
Throwable cause = e.getCause();
// 处理业务异常，如 cause instanceof ServiceException
} catch (TimeoutException e) {
// 超时降级，如返回缓存值或空对象
}
不要在 Swing / JavaFX / Servlet 线程里直接 get()
这些环境的主线程负责 UI 渲染或请求响应，阻塞会导致界面冻结或 HTTP 连接超时。常见错误模式：
立即学习“Java免费学习笔记（深入）”；
- Swing 中在 Event Dispatch Thread 调用
future.get()→ 界面假死 - Spring MVC Controller 方法里同步
get()→ Tomcat 工作线程被占满 - 正确做法是用回调（如
CompletableFuture.thenApply()）或异步 Servlet
Future 本身不支持取消后的资源清理
cancel(true) 只能尝试中断执行中的线程，但无法保证任务立即停止，尤其当任务处于 I/O 或 synchronized 块中时。
- 任务代码必须响应中断（检查
Thread.interrupted()或捕获InterruptedException） - 数据库连接、文件流等资源不会自动关闭，需在任务内部显式释放
- 若任务已开始执行且不可中断，
cancel()返回false，isCancelled()为true仅表示“取消请求已发出”
真正难处理的是“取消后仍继续跑”的任务——它既没完成也没被真正终止，还可能泄漏线程或连接。这类逻辑必须靠任务自身配合，Future 接口层面无解。
