Java设计任务取消逻辑时，何时使用自定义停止标志而非isInterrupted？

我们先理清两种方案的核心特性差异：

• 线程中断是Java原生的线程协作机制，天然适配ExecutorService.shutdownNow()、Future.cancel()等标准库API，能主动唤醒处于sleep、wait、可中断IO、阻塞队列操作等阻塞状态的线程，不需要额外实现唤醒逻辑。
• 自定义停止标志一般是声明为volatile的布尔变量，逻辑完全由业务代码控制，和线程本身的状态没有绑定。

优先选择自定义取消标志的场景 #

• 任务全程没有响应中断的阻塞逻辑
  如果你的任务是纯CPU密集型计算，全程不会调用任何会抛出InterruptedException的方法，也不需要对接线程池的标准取消流程，用自定义标志会更简洁。不需要处理中断异常捕获、中断状态复位这类冗余代码，取消逻辑直接明了，其他维护代码的人一眼就能看到控制位的位置。
• 需要细粒度的分场景取消控制
  如果你需要对不同任务、不同执行阶段做独立的取消控制，用全局的线程中断很难实现。比如同一个线程池里同时运行爬取图片和爬取文本两类任务，你需要单独停掉图片爬取任务、不影响文本爬取，给每类任务单独配自定义取消标志，实现成本比用中断低很多，逻辑也更清晰。
• 依赖的第三方库存在中断状态丢失问题
  不少第三方库的代码会错误地吞掉中断信号：比如捕获了InterruptedException之后没有重新设置线程的中断位，直接把异常吃了。如果你的任务依赖这类库，用中断机制很可能出现取消信号丢失、任务无法正常退出的问题。这时候用完全自主可控的自定义标志，不依赖线程的中断状态，稳定性会高很多。
• 任务包含不响应中断的阻塞操作
  类似旧IO的InputStream.read()、Socket连接这类阻塞操作是不响应中断的，你就算调用了interrupt()方法，线程还是会卡在阻塞逻辑上不会退出，中断机制完全失效。这种场景下用自定义标志，等阻塞操作返回之后再判断标志位退出，或者配合关闭底层IO资源的逻辑一起使用，比中断靠谱得多。

最后总结下选型规则：如果你的任务需要用到线程池的标准化取消能力，优先选线程中断机制。如果符合上面提到的几个场景，自定义停止标志是更合适的选择。

内容的提问来源于stack exchange，提问作者user6412004