为什么FutureTask不再在内部使用AQS？

Question

为什么FutureTask不再在jdk8内部使用AQS而不是jdk7？

jdk 8中有这样的评论：“避免令人惊讶的用户在*取消竞赛中保留中断状态”

我想知道更多关于这个用例的信息，如果有一个不想要的行为的例子，这个改变就会解决。

Answer 1

考虑以下情况：

• 线程A位于FutureTask的FutureTask方法中
• 线程B调用cancel(true)，它成功地将状态从RUNNING切换到CANCELLED (在Java 8之前)
• 线程A完成run()方法
• 线程B，仍然在cancel(true)中中断线程
• 线程A，现在在FutureTask外部得到一个虚假的中断

新的设计通过为INTERRUPTING引入不同的状态(在尝试中断线程之前设置)和随后设置的INTERRUPTED来解决这个问题。然后，在完成时调用以下方法：

/**
 * Ensures that any interrupt from a possible cancel(true) is only
 * delivered to a task while in run or runAndReset.
 */
private void handlePossibleCancellationInterrupt(int s) {
    // It is possible for our interrupter to stall before getting a
    // chance to interrupt us.  Let's spin-wait patiently.
    if (s == INTERRUPTING)
        while (state == INTERRUPTING)
            Thread.yield(); // wait out pending interrupt
…

请注意，这仍然不会重置被中断的线程状态。这仍然是调用方的职责，例如ExecutorService实现。但是现在已经保证在取消的情况下，在从run()方法返回时已经完成了潜在的中断，因此很容易重置标志。如果没有这一保证，在取消的情况下，中断就有可能发生在试图重置中断状态之后。