关于可见性及时性的volatile的详细语义

关于可见性及时性的volatile的详细语义

事实证明，答案和随后的讨论仅巩固了我的原始推理。我现在有一些证据可以证明：

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争辩，并且许多人会同意他的观点，即 发生在事前 ，即使未明确提及，仍然 暗示
着时间顺序。因此，我展示了我的第二个程序，该程序演示了这种情况的确切程度。

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 %sn",      Arrays.toString(aVals), Arrays.toString(aTimes));  System.out.format("Thread B read %s at %sn",      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实际上必须 预测 在时间14线程A将写入什么内容，以便知道在时间1让线程B读取什么内容。这种方法的合理性甚至可行性都令人怀疑。

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

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

术语“ 释放” 和“ 获取”
在JLS§17.4.4中定义。

该规则的一个推论是，可以 无限期推迟 仅写入而从不读取任何内容的线程的 *** 作，而不会违反 事前发生的 关系。

清除不稳定的概念

该

volatile

修改实际上是约两个截然不同的概念：

1. 该 硬的保证 ，关于它的行动将尊重 之前发生 排序;
2. 运行时尽力而为，及时发布写入的 软承诺 。

请注意，JLS并未以任何方式指定点2.，这只是一般预期而已。显然，违反诺言的实现仍然合规。随着时间的流逝，随着我们转向大规模并行体系结构，这一承诺实际上可能会变得非常灵活。因此，我希望将来将保证与承诺的结合证明是不充分的：根据需求，我们将需要一个没有另一个的，具有不同味道的一个或其他任意组合。