java - 为什么最后一个线程没有被中断？

Question

我正在尝试演示一种“随时算法”——一种可以随时停止并返回其当前结果的算法。演示算法仅返回 i 的一些数学函数，其中 i 是递增的。它检查是否被中断，如果是，则返回当前值:

    static int algorithm(int n) {
        int bestSoFar = 0;
        for (int i=0; i<n; ++i) {
            if (Thread.interrupted())
                break;
            bestSoFar = (int)Math.pow(i, 0.3);
        }
        return bestSoFar;
    }

在主程序中，我是这样使用的:

        Runnable task = () -> {
            Instant start = Instant.now();
            int bestSoFar = algorithm(1000000000);
            double durationInMillis = Duration.between(start, Instant.now()).toMillis();
            System.out.println("after "+durationInMillis+" ms, the result is "+bestSoFar);
        };

        Thread t = new Thread(task);
        t.start();
        Thread.sleep(1);
        t.interrupt();

        t = new Thread(task);
        t.start();
        Thread.sleep(10);
        t.interrupt();

        t = new Thread(task);
        t.start();
        Thread.sleep(100);
        t.interrupt();

        t = new Thread(task);
        t.start();
        Thread.sleep(1000);
        t.interrupt();
    }
}

当我运行这个程序时，我得到以下输入:

after 0.0 ms, the result is 7
after 10.0 ms, the result is 36
after 100.0 ms, the result is 85
after 21952.0 ms, the result is 501

也就是说，前三个线程在我告诉它们时确实被打断了，但最后一个线程在 1 秒后没有被打断——它继续工作了将近 22 秒。为什么会这样？

编辑:我使用带有超时的 Future.get 得到类似的结果。在这段代码中:

    Instant start = Instant.now();
    ExecutorService executor = Executors.newCachedThreadPool();
    Future<?> future = executor.submit(task);
    try {
        future.get(800, TimeUnit.MILLISECONDS);
    } catch (TimeoutException e) {
        future.cancel(true);
        double durationInMillis = Duration.between(start, Instant.now()).toMillis();
        System.out.println("Timeout after "+durationInMillis+" [ms]");
    }

如果超时最多为 800，则一切正常，它会打印类似“806.0 [ms] 后超时”的内容。但如果超时为 900，它会打印“5084.0 [ms] 后超时”。

编辑 2:我的电脑有 4 个内核。该程序在 Open JDK 8 上运行。

Answer 1

我可以确认这是一个 HotSpot JVM 错误。这是我对问题的初步分析。

@AdamSkywalker 完全正确地假设该问题与 HotSpot HIT 编译器中的安全点消除优化有关。尽管错误JDK-8154302看起来很相似，实际上是不同的问题。

什么是安全点问题

Safepoint是停止应用程序线程以执行需要 stop-the-world pause 的操作的 JVM 机制. HotSpot 中的安全点是协作的，即应用程序线程定期检查它们是否需要停止。这种检查通常发生在方法导出和内部循环中。

当然，这个支票不是免费的。因此，出于性能原因，JVM 试图消除冗余的安全点轮询。其中一种优化是从计数循环中删除安全点轮询 - 形式的循环

    for (int i = 0; i < N; i++)

或等价物。这里 N 是 int 类型的循环不变量。

通常这些循环运行时间很短，但在某些情况下它们可能需要很长时间，例如当 N = 2_000_000_000 时。安全点操作要求停止所有 Java 线程(不包括运行 native 方法的线程)。也就是说，一个长时间运行的计数循环可能会延迟整个安全点操作，所有其他线程将等待这个循环停止。

这正是 JDK-8154302 中发生的事情.注意

    int l = 0;
    while (true) {
        if (++l == 0) ...
    }

只是表示 2³² 迭代计数循环的另一种方式。当 Thread.sleep 从 native 函数返回并发现请求安全点操作时，它会停止并等待长时间运行的计数循环也完成。这就是奇怪的延迟的来源。

有一个任务可以解决这个问题 - JDK-8186027 .这个想法是将一个长循环分成两部分:

    for (int i = 0; i < N; i += step) {
        for (int j = 0; j < step; j++) {
            // loop body
        }
        safepoint_poll();
    }

它还没有实现，但修复是针对 JDK 10 的。同时有一个解决方法:JVM 标志 -XX:+UseCountedLoopSafepoints 也会在计数循环内强制进行安全点检查。

Thread.interrupted() 有什么问题

我很确定Thread.sleep bug将作为 Loop strip mining issue 的副本关闭.您可以使用 -XX:+UseCountedLoopSafepoints 选项验证此错误是否消失。

不幸的是，这个选项对解决原来的问题没有帮助。我捕获了原始问题中 algorithm 挂起的时刻，并查看了 gdb 下正在执行的代码:

loop_begin:
  0x00002aaaabe903d0:  mov    %ecx,%r11d
  0x00002aaaabe903d3:  inc    %r11d             ; i++
  0x00002aaaabe903d6:  cmp    %ebp,%r11d        ; if (i >= n)
  0x00002aaaabe903d9:  jge    0x2aaaabe90413    ;     break;
  0x00002aaaabe903db:  mov    %ecx,%r8d
  0x00002aaaabe903de:  mov    %r11d,%ecx
  0x00002aaaabe903e1:  mov    0x1d0(%r15),%rsi  ; rsi = Thread.current();
  0x00002aaaabe903e8:  mov    0x1d0(%r15),%r10  ; r10 = Thread.current();
  0x00002aaaabe903ef:  cmp    %rsi,%r10         ; if (rsi != r10)
  0x00002aaaabe903f2:  jne    0x2aaaabe903b9    ;     goto slow_path;
  0x00002aaaabe903f4:  mov    0x128(%r15),%r10  ; r10 = current_os_thread();
  0x00002aaaabe903fb:  mov    0x14(%r10),%r11d  ; isInterrupted = r10.interrupt_flag;
  0x00002aaaabe903ff:  test   %r11d,%r11d       ; if (!isInterrupted)
  0x00002aaaabe90402:  je     0x2aaaabe903d0    ;     goto loop_begin

algorithm 方法中的循环是这样编译的。这里没有安全点轮询，即使设置了 -XX:+UseCountedLoopSafepoints。

看起来安全点检查被错误地消除了，因为 Thread.isInterrupted 调用应该检查安全点本身。但是，Thread.isInterrupted 是 HotSpot 的内部方法。这意味着没有真正的 native 方法调用，但 JIT 将对 Thread.isInterrupted 的调用替换为内部没有安全点检查的机器指令序列。

我会尽快将错误报告给 Oracle。同时，解决方法是将循环计数器的类型从 int 更改为 long。如果将循环重写为

    for (long i=0; i<n; ++i) { ...

不会再有奇怪的延迟了。