Java thread.start 可以重新排序吗？

Question

考虑以下从Memory Consistency - happens-before relationship in Java借用的场景：

package happen.before;

public class HappenBeforeRelationship {

private static int counter = 0;

private static void threadPrintMessage(String msg){
    System.out.printf("[Thread %s] %s\n", Thread.currentThread().getName(), msg);
}

public static void main(String[] args) {
    threadPrintMessage("Increase counter: " + ++counter);
    Thread t = new Thread(new CounterRunnable());
    t.start();
    try {
        t.join();
    } catch (InterruptedException e) {
        threadPrintMessage("Counter is interrupted");
    }
    threadPrintMessage("Finish count: " + counter);
}

private static class CounterRunnable implements Runnable {
    @Override
    public void run() {
        threadPrintMessage("start count: " + counter);
        counter++;
        threadPrintMessage("stop count: " + counter);
    }
}

我知道 JLS 中有一条规则保证 Thread.start 在启动线程中的所有操作之前发生。

当一个语句调用 Thread.start 时，每个语句都有一个 与该语句的发生之前的关系也有 与新执行的每个语句的发生前关系 线。导致创建新代码的代码的影响 线程对新线程可见。

但它并没有声称Thread.start 之前的语句与它有发生之前的关系。

所以我想知道 Thread.start 是否可以重新排序以使程序无法获得预期的输出（计数器 = 2）？如果不是，JLS 的哪一部分指定Thread.start 不能重新排序？

---

另一个问题：

如果join() 放在threadPrintMessage("Finish count: " + counter); 之后会发生什么？ stop count: 1 会不会被打印出来？

Answer 1

Thread.start 调用之前的动作与JLS§17.4.5 引起的新线程的开始之间存在顺序关系：

• 如果 x 和 y 是同一线程的操作，并且 x 在程序顺序中位于 y 之前，然后 hb(x, y)。
• …
• 如果 hb(x, y) 和 hb(y, z)，则 hb(x, z)。

稍后在同一部分中，您的问题保证中已经提到：

• 在线程上调用start()在开始线程中的任何操作之前发生。

由于 happens-before 关系的传递性，在调用 start() 之前主线程的操作与操作之间存在 happens-before 关系在开始的线程中。同样，在启动线程的操作和主线程的join 调用的成功返回之间存在happens-before关系。

换句话说，只要您没有遇到InterruptedException，更新就会正确排序，打印结果将为2。然而，这并不意味着随着 JLS§17.4.5 的继续，这些操作永远不会重新排序：

应该注意的是，两个动作之间存在 happens-before 关系并不一定意味着它们必须在实现中以该顺序发生。如果重新排序产生与合法执行一致的结果，则不是非法的。

换句话说，happens-before 关系是一个高级概念，它允许您确定程序执行的合法结果。如果像在这个例子中一样，在程序末尾的counter 中有2 是唯一合法的结果（如上所述，假设没有发生中断），JVM 可能会尽可能多地安排代码，只要程序会产生在最后的counter 中包含2 的法律结果。

您不应该再为是否可以重新排序而烦恼。这是一个不重要的实现细节。如果没有适当的 happens-before 关系，您可能会遇到出现乱序的更新，但也可能会错过更新或创建不一致的状态，因此专注于一个实现细节是没有意义的可能会在损坏的程序中导致意外的副作用。相反，应该关注什么才是正确的程序。