可能有助于解释为什么首先存在这样的规则。
Java是一种过程性语言。也就是说，您要告诉Java如何替您完成某些操作。如果Java不按照您编写的顺序执行指令，那么它显然无法正常工作。例如，在下面的示例中，如果Java按照2->1->3的顺序执行，则炖菜将被毁坏。
1. Take lid off
2. Pour salt in
3. Cook for 3 hours
那么，为什么规则不直接说“Java按照你编写的顺序执行所编写的内容”呢？简而言之，因为Java很聪明。请看以下示例：
1. Take eggs out of the freezer
2. Take lid off
3. Take milk out of the freezer
4. Pour egg and milk in
5. Cook for 3 hours
如果 Java 跟我一样，它会按顺序执行。但是 Java 足够聪明，它理解到如果按照 1 -> 3 -> 2 -> 4 -> 5 的顺序执行更有效，并且结果与直接按顺序执行相同（你不必再走一次去冰箱，而且这不会改变食谱）。
那么规则“一个线程中的每个操作都发生在该线程中程序顺序后面的每个操作之前”试图说的是，“在单个线程中，您的程序将按照您编写的确切顺序运行。我们可能会在幕后更改排序，但我们确保不会更改输出。”
到目前为止还好。为什么跨多个线程不这样做？在多线程编程中，Java 自动执行这些操作并不够聪明。对于某些操作（例如加入/启动线程，使用锁（监视器）等），它会自动执行，但对于其他操作，您需要显式告诉它不要重新排序以更改程序输出（例如字段上的 "volatile" 标记、锁的使用等）。
注意：
关于“happens-before 关系”的快速补充说明。这是一种花哨的方式来表达无论 Java 进行什么重排序，A 事情都会在 B 事情发生之前发生。在我们奇怪的后来的炖菜例子中，“步骤 1 和 3 在倒入鸡蛋和牛奶之前发生”。例如，“步骤 1 和 3 不需要‘happens-before’关系，因为它们彼此不依赖”。
关于附加问题和对评论的回答
首先，让我们确定编程世界中“时间”的含义。在编程中，我们有“绝对时间”（现在世界上的时间是多少？）和“相对时间”（自 x 以来经过了多长时间？）的概念。在理想情况下，时间就是时间，但除非我们内置原子钟，否则必须不时地校正绝对时间。另一方面，对于相对时间，我们不希望进行修正，因为我们只关心事件之间的差异。
在 Java 中，System.currentTime() 处理绝对时间，System.nanoTime() 处理相对时间。这就是为什么 nanoTime 的 Javadoc 明确指出：“该方法仅用于测量经过的时间，与系统或挂钟时间的任何其他概念无关”。
实际上，currentTimeMillis 和 nanoTime 都是本地调用，因此编译器无法实际证明重新排序不会影响正确性，这意味着它不会重新排序执行。
但是让我们想象一下，我们想编写一个实际查看本机代码并重新排序一切（只要合法）的编译器实现。当我们查看 JLS 时，它告诉我们可以重新排序任何东西，只要不能被检测到。作为编译器编写者，我们必须决定重新排序是否会违反语义。对于相对时间（nanoTime），如果重新排序执行，显然是无用的（即违反语义）。那么，如果我们为绝对时间（currentTimeMillis）重新排序，是否会违反语义？只要我们可以将与世界时间源（例如系统时钟）的差限制在我们决定的任何值（如“50 毫秒”）之内，我认为不会。针对以下示例：
long tick = System.currentTimeMillis();
result = compute();
long tock = System.currentTimeMillis();
print(result + ":" + tick - tock);
如果编译器可以证明compute()的执行时间少于我们允许的系统时钟最大差异，则可以将其排序如下：
long tick = System.currentTimeMillis();
long tock = System.currentTimeMillis();
result = compute();
print(result + ":" + tick - tock);
既然这样做不违反我们定义的规范，因此也不会违反语义。
您还问为什么这不包含在JLS中。我认为答案是“为了保持JLS简短”。但是我对这个领域了解不多，因此您可能需要单独提出一个问题来询问。
*：在实际实现中，这种差异是平台依赖的。
synchronized块（与单线程程序顺序无关），那么由于没有任何操作对其他操作产生影响，它们可以自由地重新排序。 - Andrew Bissell