futuretask.cancel(true)不抛interruptedexception，而是通过中断线程使任务内可中断操作（如sleep）抛出该异常；需在任务中捕获并恢复中断状态或退出；cancel后get()抛cancellationexception；主线程调用get()被中断则抛interruptedexception，应恢复中断并清理资源。
FutureTask.cancel(true)本身不会抛出InterruptedException，真正可能抛出该异常的是任务内部的可中断操作（如Thread.sleep()、BlockingQueue.take()、CountDownLatch.await()等）——当cancel(true)触发线程中断后，这些方法检测到中断状态就会主动抛出InterruptedException。处理的关键不是“捕获cancel的异常”，而是**在任务逻辑中正确响应中断并妥善处理该异常**。
任务代码里要主动捕获并响应InterruptedException
一旦任务中调用可中断方法，就必须处理其抛出的InterruptedException：
- 不要简单地吞掉异常（比如只写catch (InterruptedException e) {}）
- 通常应恢复中断状态：Thread.currentThread().interrupt()，以便上层逻辑能感知中断意图
- 或根据业务直接退出当前逻辑（如return、break循环、抛出自定义异常）
- 避免在catch块中执行耗时或阻塞操作，否则会延迟任务终止
取消后调用get()会抛CancellationException，不是InterruptedException
FutureTask被成功cancel(true)后，后续调用future.get()不会抛InterruptedException，而是抛CancellationException：
- 这是明确标识“任务被用户取消”，与“等待被中断”无关
- 需单独catch CancellationException，用于区分取消场景和执行异常
- 此时无需恢复中断，因为中断是取消动作引发的，不是调用线程自身被中断
主线程等待结果时也可能遇到InterruptedException
如果你在主线程中调用future.get()（尤其是无参版本），而该线程自身被外部中断（比如收到shutdown信号），则get()会抛InterruptedException：
- 这与FutureTask是否被取消无关，是调用线程的等待行为被中断
- 标准做法是捕获后立即恢复中断状态：Thread.currentThread().interrupt()
- 然后按需清理资源或退出当前流程，不可忽略
资源清理要兼顾中断与正常完成路径
无论任务因完成、异常还是取消结束，都应确保关键资源释放：
- 在try-catch-finally或try-with-resources中管理文件、连接、锁等
- 在检测到Thread.interrupted()或捕获InterruptedException后，优先关闭打开的资源
- 避免把清理逻辑全放在finally里——如果finally中发生长时间阻塞，会拖慢取消响应
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
