考虑一个 volatile int sharedVar。我们知道 JLS 为我们提供了以下保证:

1. 写入线程 w 的每个 Action 在其将值 i 写入 sharedVar 之前按程序顺序 happens-before 写 Action ；
2. w 写入值 i happens-before 从 成功读取 i sharedVar 由读取线程 r;
3. 读取线程r从sharedVar成功读取ihappens-before所有后续 Action r 按程序顺序排列。

但是，对于何时读取线程将观察到值i，仍然没有给出挂钟时间保证。一个简单地从不让读取线程看到该值仍然符合此协定的实现。

我已经考虑了一段时间，我看不出有任何漏洞，但我认为一定有。请指出我推理的漏洞。

最佳答案

事实证明，答案和随后的讨论只是巩固了我最初的推理。我现在有一些东西可以证明:

1. 以读线程在写线程开始执行之前完全执行的情况为例；
2. 注意此特定运行创建的同步顺序；
3. 现在以挂钟时间移动线程，以便它们并行执行，但保持相同的同步顺序。

由于 Java 内存模型没有引用挂钟时间，因此不会有任何障碍。您现在有两个线程与读取线程并行执行，观察到写入线程没有执行任何操作。 QED。

示例1:一写一读线程

为了使这一发现最大程度地尖锐和真实，请考虑以下程序:

static volatile int sharedVar;

public static void main(String[] args) throws Exception {
  final long startTime = System.currentTimeMillis();
  final long[] aTimes = new long[5], bTimes = new long[5];
  final Thread
    a = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        sharedVar = 1;
        aTimes[i] = System.currentTimeMillis()-startTime;
        briefPause();
      }
    }},
    b = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        bTimes[i] = sharedVar == 0?
            System.currentTimeMillis()-startTime : -1;
        briefPause();
      }
    }};
  a.start(); b.start();
  a.join(); b.join();
  System.out.println("Thread A wrote 1 at: " + Arrays.toString(aTimes));
  System.out.println("Thread B read 0 at: " + Arrays.toString(bTimes));
}
static void briefPause() {
  try { Thread.sleep(3); }
  catch (InterruptedException e) {throw new RuntimeException(e);}
}

就 JLS 而言，这是一个合法的输出:

Thread A wrote 1 at: [0, 2, 5, 7, 9]
Thread B read 0 at: [0, 2, 5, 7, 9]

请注意，我不依赖 currentTimeMillis 的任何故障报告。报道的时间是真实的。但是，实现确实选择了使写入线程的所有操作仅在读取线程的所有操作之后才可见。

示例2:读写两个线程

现在@StephenC 争辩说，许多人会同意他的观点，即 happens-before，即使没有明确提及，仍然暗示时间顺序。因此，我提出了我的第二个程序，它展示了这种情况的确切程度。

public static void main(String[] args) throws Exception {
  final long startTime = System.currentTimeMillis();
  final long[] aTimes = new long[5], bTimes = new long[5];
  final int[] aVals = new int[5], bVals = new int[5];
  final Thread
    a = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        aVals[i] = sharedVar++;
        aTimes[i] = System.currentTimeMillis()-startTime;
        briefPause();
      }
    }},
    b = new Thread() { public void run() {
      for (int i = 0; i < 5; i++) {
        bVals[i] = sharedVar++;
        bTimes[i] = System.currentTimeMillis()-startTime;
        briefPause();
      }
    }};
  a.start(); b.start();
  a.join(); b.join();
  System.out.format("Thread A read %s at %s\n",
      Arrays.toString(aVals), Arrays.toString(aTimes));
  System.out.format("Thread B read %s at %s\n",
      Arrays.toString(bVals), Arrays.toString(bTimes));
}

只是为了帮助理解代码，这将是一个典型的、真实的结果:

Thread A read [0, 2, 3, 6, 8] at [1, 4, 8, 11, 14]
Thread B read [1, 2, 4, 5, 7] at [1, 4, 8, 11, 14]

另一方面，您永远不会想到会看到这样的事情，但按照 JMM 的标准，它仍然是合法的:

Thread A read [0, 1, 2, 3, 4] at [1, 4, 8, 11, 14]
Thread B read [5, 6, 7, 8, 9] at [1, 4, 8, 11, 14]

JVM 实际上必须预测线程 A 在时间 14 将写入什么，以便知道让线程 B 在时间 1 读取什么。这样做的合理性甚至可行性都值得怀疑.

据此，我们可以定义 JVM 实现可以采取的以下现实自由:

线程的任何不间断释放 Action 序列的可见性可以安全地推迟到中断它的获取 Action 之前。

release 和 acquire 这两个术语在 JLS §17.4.4 中定义。 .

这条规则的一个推论是，一个只写而从不读任何东西的线程的 Action 可以无限期推迟，而不会违反 happens-before 关系。 p>

清除 volatile 概念

volatile 修饰符实际上是关于两个不同的概念:

1. 硬保证，对它的操作将遵守 happens-before 顺序；
2. 运行时尽最大努力及时发布写入的软 promise 。

请注意第 2 点，JLS 并未以任何方式指定，它只是出于普遍预期。显然，违背 promise 的实现仍然是合规的。随着时间的推移，随着我们转向大规模并行架构，这一 promise 可能确实被证明是相当灵活的。因此，我希望将来将保证与 promise 的合并证明是不够的:根据要求，我们需要一个没有另一个，一个有不同风格的另一个，或者任何数量的其他组合。

关于java - volatile关于可见性及时性的详细语义，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11761552/