FutureTask.get() 永久阻塞会耗尽 Tomcat 工作线程，导致请求堆积和服务不可用；根本解法是设置超时、隔离执行环境、确保任务响应中断，并辅以监控与熔断兜底。
FutureTask.get() 永久阻塞会耗尽 Tomcat 的工作线程，造成请求堆积、服务不可用。根本解法不是避免使用 FutureTask，而是控制阻塞行为、设置超时、隔离执行环境。
必须设置超时时间
调用 get() 时不带超时参数是最大风险点。永远不要写 future.get()，而应始终指定合理 timeout：
- 根据业务场景设定：IO 密集型任务建议 3–10 秒；计算型可更短（如 2–5 秒）
- 使用
future.get(5, TimeUnit.SECONDS)，超时抛出TimeoutException - 捕获 TimeoutException 后需主动 cancel：
future.cancel(true)，中断底层线程（前提是任务支持响应中断）
避免在 Tomcat 线程中直接执行长耗时 FutureTask
Tomcat 的 worker 线程本质是请求处理线程，不适合承担可能长时间阻塞或计算密集的任务：
- 将 FutureTask 提交到独立的业务线程池（如
ThreadPoolExecutor），而非直接在 Servlet 线程里 new Thread 或用 Executors.newCachedThreadPool - 线程池需配置合理核心数、队列容量和拒绝策略（推荐
CallerRunsPolicy防雪崩） - 示例：用 Spring 的
@Async+ 自定义线程池，或手动管理ExecutorService实例（单例、容器管理生命周期）
任务本身要支持可取消与中断响应
即使设置了超时并调用了 cancel(true)，若任务内部忽略中断状态，线程仍无法退出：
立即学习“Java免费学习笔记（深入）”；
- 在循环体中定期检查
Thread.interrupted()或isInterrupted() - 阻塞调用（如
Thread.sleep、Object.wait、NIO channel.read）会响应中断并抛出InterruptedException，需正确处理（恢复中断状态或退出） - 避免在 Runnable/Callable 中使用无法中断的 native 调用或死循环无检查
监控与兜底防护
靠编码规范无法 100% 避免问题，需运行时防护：
- 通过 JMX 或 Micrometer 暴露 FutureTask 执行时长、超时次数、cancel 成功率等指标
- 对关键异步操作添加熔断（如使用 Resilience4j 的 TimeLimiter + CircuitBreaker 组合）
- 在 Filter 或 Interceptor 中限制单个请求内允许启动的异步任务数量，防止恶意或异常请求拖垮线程池
不复杂但容易忽略：超时值不是越长越好，也不是越短越安全；它需要结合下游依赖的 P99 延迟、重试策略和用户体验综合设定。同时，cancel(true) 是否真正生效，取决于任务代码是否尊重中断协议。
