FutureTask.cancel(true)是否生效取决于任务是否响应中断；需在任务中主动检查中断状态或捕获InterruptedException；cancel(false)仅对未启动任务有效；get()必须用带超时版本并处理TimeoutException、CancellationException和ExecutionException。
FutureTask 不能直接取消正在运行的任务？
不是不能，而是 cancel(true) 是否生效，取决于任务内部是否响应中断。很多新手以为调用一次 cancel(true) 就能立刻停掉线程，结果发现 isDone() 返回 true，但任务逻辑还在跑——这是因为目标线程没检查 Thread.interrupted() 或没把 InterruptedException 向上抛。
- 必须在任务逻辑中主动轮询中断状态，比如在循环里加
if (Thread.currentThread().isInterrupted()) return; - 阻塞方法（如
Thread.sleep()、Object.wait()、BlockingQueue.take()）会响应中断并抛出InterruptedException，此时要捕获并退出，或重新设置中断状态：Thread.currentThread().interrupt(); -
cancel(false)只取消“尚未启动”的任务，对RUNNING状态完全无效
get() 阻塞时如何安全超时并释放资源？
直接调用无参 get() 是最常见隐患：一旦任务卡死或永远不完成，调用线程就永久挂起。生产环境必须用带超时的版本，并配合异常处理清理资源。
- 优先使用
get(long timeout, TimeUnit unit)，超时后抛TimeoutException，而非让线程无限等待 - 捕获
CancellationException表示任务被取消，ExecutionException表示任务内抛了异常，两者都需要显式处理，不能只 catchException - 如果任务打开了文件、网络连接等资源，别指望
FutureTask自动关——得在finally块或try-with-resources中手动释放
submit(Runnable, T) 和 new FutureTask(Callable) 的行为差异
表面上都能得到 Future，但底层状态流转和取消语义不同。尤其当 Runnable 没有显式处理中断时，submit(runnable, result) 包装出的 Future 可能无法真正中断执行。
-
submit(Runnable, T)返回的是FutureTask的子类（如RunnableAdapter），它把Runnable转成Callable，但不会自动注入中断检查逻辑 -
new FutureTask(new Callable<t>() { ... })</t>更可控：你能完全掌控call()内部逻辑，包括中断响应、重试、日志等 - 若需精确控制生命周期（比如任务中途要暂停/恢复），直接用
FutureTask构造 + 手动run()/cancel()，比丢给ExecutorService.submit()更透明
重复调用 run() 或 cancel() 会怎样？
FutureTask.run() 不是幂等的：多次调用只会执行一次，后续调用直接忽略；但 cancel() 在任务已完成（isDone() == true）后再调，返回 false，且不报错——这容易掩盖误操作。
立即学习“Java免费学习笔记（深入）”；
- 不要在未确认状态前反复调
cancel()，它不会“加强”取消效果，只是返回布尔值告诉你“这次有没有成功取消” -
run()被调用后，即使任务抛异常，状态也变成DONE，再次调用run()无效果，但也不会抛异常 - 判断任务是否真被取消，不能只看
cancel(true)返回true，还得结合isCancelled()和实际业务状态（比如数据库写入是否回滚）
