我已经写了很多有关InterruptedException和中断线程的文章 。 简而言之，如果您没有Future.cancel()调用Future.cancel()那么Future将终止待处理的get() ，但还将尝试中断基础线程。 这是一个非常重要的功能，可以更好地利用线程池。 我还写信总是比标准Future更喜欢CompletableFuture 。 事实证明，功能更强大的Future弟兄没有那么优雅地处理cancel() 。 考虑以下任务，我们稍后将在整个测试中使用以下任务：
class InterruptibleTask implements Runnable {
private final CountDownLatch started = new CountDownLatch(1)
private final CountDownLatch interrupted = new CountDownLatch(1)
@Override
void run() {
started.countDown()
try {
Thread.sleep(10_000)
} catch (InterruptedException ignored) {
interrupted.countDown()
}
}
void blockUntilStarted() {
started.await()
}
void blockUntilInterrupted() {
assert interrupted.await(1, TimeUnit.SECONDS)
}
}
客户端线程可以检查InterruptibleTask以查看其是否已开始或被中断。 首先，让我们看一下InterruptibleTask对外部的cancel()反应：
def "Future is cancelled without exception"() {
given:
def task = new InterruptibleTask()
def future = myThreadPool.submit(task)
task.blockUntilStarted()
and:
future.cancel(true)
when:
future.get()
then:
thrown(CancellationException)
}
def "CompletableFuture is cancelled via CancellationException"() {
given:
def task = new InterruptibleTask()
def future = CompletableFuture.supplyAsync({task.run()} as Supplier, myThreadPool)
task.blockUntilStarted()
and:
future.cancel(true)
when:
future.get()
then:
thrown(CancellationException)
}
到目前为止，一切都很好。 显然， Future和CompletableFuture工作方式几乎相同-在取消结果后检索结果会引发CancellationException 。 但是myThreadPool线程呢？ 我以为它会被游泳池打断，从而被回收，我怎么了！
def "should cancel Future"() {
given:
def task = new InterruptibleTask()
def future = myThreadPool.submit(task)
task.blockUntilStarted()
when:
future.cancel(true)
then:
task.blockUntilInterrupted()
}
@Ignore("Fails with CompletableFuture")
def "should cancel CompletableFuture"() {
given:
def task = new InterruptibleTask()
def future = CompletableFuture.supplyAsync({task.run()} as Supplier, myThreadPool)
task.blockUntilStarted()
when:
future.cancel(true)
then:
task.blockUntilInterrupted()
}
第一个测试将普通的Runnable提交给ExecutorService并等待其启动。 稍后，我们取消Future并等待直到观察到InterruptedException 。 当基础线程被中断时， blockUntilInterrupted()将返回。 但是，第二次测试失败。 CompletableFuture.cancel()永远不会中断基础线程，因此尽管Future看起来好像已被取消，但后备线程仍在运行，并且sleep()不会抛出InterruptedException 。 错误或功能？ 它已记录在案 ，因此很遗憾地提供一个功能：
参数：
mayInterruptIfRunning–此值在此实现中无效，因为不使用中断来控制处理。
您说RTFM，但是为什么CompletableFuture这样工作？ 首先，让我们研究“旧的” Future实现与CompletableFuture有何不同。 从ExecutorService.submit()返回的FutureTask具有以下cancel()实现（我使用类似的非线程安全Java代码删除了Unsafe ，因此仅将其视为伪代码）：
public boolean cancel(boolean mayInterruptIfRunning) {
if (state != NEW)
return false;
state = mayInterruptIfRunning ? INTERRUPTING : CANCELLED;
try {
if (mayInterruptIfRunning) {
try {
Thread t = runner;
if (t != null)
t.interrupt();
} finally { // final state
state = INTERRUPTED;
}
}
} finally {
finishCompletion();
}
return true;
}
FutureTask具有一个遵循该状态图的state变量：
在的情况下， cancel()我们可以进入CANCELLED状态或去INTERRUPTED通过INTERRUPTING 。 核心部分是我们拿runner线程（如果存在的，也就是说，如果当前正在执行的任务），我们尽量打断它。 该分支负责急切和强制中断已运行的线程。 最后，我们必须通知阻塞的所有线程Future.get()中finishCompletion()这里无关紧要）。 因此，很明显，多大的Future取消已经运行的任务。 那CompletableFuture呢？ cancel()伪代码：
public boolean cancel(boolean mayInterruptIfRunning) {
boolean cancelled = false;
if (result == null) {
result = new AltResult(new CancellationException());
cancelled = true;
}
postComplete();
return cancelled || isCancelled();
}
令人失望的是，我们几乎没有将result设置为CancellationException ，而忽略了mayInterruptIfRunning标志。 postComplete()也有类似的作用finishCompletion() -在通知未来注册的所有悬而未决的回调。 它的实现相当令人不快（使用非阻塞式Treiber stack ），但是它绝对不会中断任何底层线程。
原因和含义
在CompletableFuture情况下，有限的cancel()不是错误，而是设计决定。 CompletableFuture并非固有地绑定到任何线程，而Future几乎总是代表后台任务。 从零开始创建CompletableFuture （ new CompletableFuture<>() ）是完美的，其中根本没有要取消的底层线程。 我仍然不禁感到大多数CompletableFuture 都将具有关联的任务和后台线程。 在这种情况下， cancel()可能会出现故障。 我不再建议用CompletableFuture盲目地替换Future ，因为它可能会更改依赖cancel()的应用程序的行为。 这意味着CompletableFuture故意违反了Liskov替换原则 -这是需要考虑的严重问题。
翻译自: https://www.javacodegeeks.com/2015/03/completablefuture-cant-be-interrupted.html