Java内存模型修订了！
传统的Java内存模型涵盖了很多Java语言的语义保证。在这篇文章中，我们将重点介绍其中的几个语义，以更深入地了解他们。对于本文中描述的语义，我们还将尝试体会对现有Java内存模型更新的动机。本文中与JMM未来更新相关的讨论，将被称为JMM9。
1. Java内存模型
现有的Java内存模型，如JSR133（以下称为JMM-JSR133）中所定义的，为共享内存指定了一致性模型，并且有助于为开发者提供与 JMM-JSR133表述一致的定义。JMM-JSR133规范的目标是确保线程通过内存交互语义的精确定义，以便允许优化并提供清晰的编程模型。 JMM-JSR133旨在提供定义和语义，使多线程程序不仅是正确的，而且是高性能的，并对现有代码库的影响微乎其微。
考虑到这一点，我们来过一下JMM-JSR133中，过分指定或者指定不足的语义保证，同时重点放到社区广泛讨论的，关于我们如何在JMM9对其改进的话题上。
2. JMM9 - 顺序一致性 - 数据竞态自由问题
JMM-JSR133谈到了相对于操作的程序执行。结合有序操作的执行，描述了这些操作之间的关系。在这篇文章中，我们将扩展一些这样的顺序和关 系，进而讨论一下什么是顺序一致的执行。让我们先从“程序顺序”开始。每个线程的程序顺序是一个总体顺序，表示通过该线程执行的所有操作的顺序。有时候， 并不是所有操作都需要按序执行的。因此，有一些关系仅是部分有序的关系。例如，“happens-before”和“synchronized- with”两个就是部分有序关系。当一个操作发生在另一个操作之前；第一个操作不仅对第二个操作是可见的，而且其顺序在第二个操作之前。这两个操作之间的 关系被称为是happens-before关系。有时，有些特殊操作需要指定顺序，他们被称为“同步操作”。volatile的读取和写入、 monitor的锁定和解锁等都是同步操作的例子。一个同步操作会引起该操作的“synchronized-with”关系。synchronized- with关系是偏序的，这意味着并非所有两两的同步操作都包含这个关系之内。所有同步操作的总体顺序被称为“同步顺序”，每个执行都有一个同步顺序。
现在让我们谈谈顺序一致的执行。当所有的读写操作是总体有序执行时，被认为是顺序一致的（SC）。在SC执行中，读操作总是能看到最后一次写入特 定变量的值。当SC执行表现为没有“数据竞态”时，该程序被认为是数据竞态自由（DRF）的。当程序中有两个不具备happens-before关系顺序 的访问，他们访问的变量相同且至少其中之一是一个写访问时，就会发生数据竞态。数据竞态自由的顺序一致（SC for DRF）意味着DRF程序的行为是顺序一致的。但是严格支持顺序一致是以牺牲性能为代价的，大多数系统会对内存中的操作重新排序，以提高执行速度，并“隐 藏”昂贵操作的延迟。同时，编译器也会对代码重新排序以优化执行。在保证严格顺序的一致性的场景中，不能进行这些内存操作重新排序或代码优化，因此性能会 受到影响。JMM-JSR133已经使用底层编译器、高速缓冲存储器的相互作用和对程序不可见的JIT，合并了松散排序限制和任何重新排序。
注：昂贵操作是那些占用大量的CPU周期来完成、阻止执行流水线。
对于JMM9来说，性能是一个重要的考虑因素，而且任何一门编程语言的内存模型，理论上，都应该让开发者可以利用内存模型架构上弱有序（weakly-ordered）的优势。成功的实现和示例是放松严格的顺序，尤其是在弱有序的架构上。
注：弱序是指可以对读取和写入重新排序，并且需要显式的内存屏障遏制这种重新排序的架构。
3. JMM9 - 无中生有问题
JMM-JSR133另一个主要的语义是对“无中生有”（Out-of Thin Air，OoTA）值的禁止。happens-before模型有时会创建变量值并“无中生有”地读取，因为它不包含因果条件。有一点非常重要，由自身引 起的关系不会采用数据和控制依赖的概念，我们将在下面正确同步代码的例子看到，非法写入是由写入本身引起的。
（注：x和y初始化为0） -
这段码是happens-before一致的，但不是真正的顺序一致。例如，如果r1看到为x=42的写入，并且r2看到Y=42的写入，x和y的值都是42，这是一个数据竞态条件的结果。
这里，写入变量都在读取变量之前，读取将看到相关的写入，这将导致OoTA结果。
注：数据竞态可能产生推测的结果，这将最终把自己变成自我实现的预言。OoTA保证是关于秉承因果关系的规则。目前的想法是，因果关系可以避免写入推测。JMM9旨在寻找OoTA的原因和改进方法，以避免OoTA。
为了禁止OoTA值，一些写入需要等待他们的读取来避免数据竞态。因此，JMM-JSR133定义的OoTA禁止正式拒绝OoTA读取。这个正式的定义包括内存模型的“执行和因果条件”。基本上，当所有的程序操作提交时，一个良好的执行要满足因果条件。
注：在每次读取可以看到对同一变量的写入时，一个良好的执行遵循在一个线程内、happens-before和synchronization-order一致地执行。
正如你可能已经知道的，JMM-JSR133定义严格定义，不让OoTA值侵袭。JMM9旨在发现和纠正正式的定义，以便允许一些常见的优化。
4. JMM9 非Volatile变量上的Volatile操作
首先，关键字'Volatile'是什么意思呢？Java的‘volatile’保证了线程间的交互，使得当一个线程写入一个volatile变量，不仅这次写入对其他线程可见，而且其他线程可以看到该线程所有的对volatile变量的写入。
那么对于non-volatile变量又发生了什么呢？非volatile变量没有volatile关键字保证交互的好处。因此，编译器可以使 用non-volatile变量的缓存值而不是‘volatile’保证，‘volatile’变量将总是从内存中读取。happens-before模 型可以用来绑定同步访问到非volatile变量上。
注：声明的任何字段为‘volatile’并不意味着有锁参与。因此volatile比使用锁来同步更便宜。但是着重要注意的是，当方法中有多个volatile字段时，可能比使用锁更昂贵。
5. JMM9 - 读写原子性问题和字分裂问题
JMM-JSR133也有为共享内存并行算法提供的读取和写入的原子性保证（使用异常）。异常是为non-volatile的长整型和双精度浮 点型的写入被视为两个独立的写入而定义的。因此，一个64位的值可以分别写入两个32位，一个线程正在执行读的时候，如果其中的一个写入仍未完成，该线程 可能会看到只有一半正确的值，从而失去原子性。这是原子性保证依赖于底层硬件和内存子系统的一个例子。例如，底层汇编指令应该能够处理的操作数的大小，以 便保证原子性，否则如果读或写操作必须被分成多于一个的操作，最终将破坏原子性（正如例子中的non-volatile的长整型和双精度浮点型的值）。类 似地，如果因为实现产生一个以上的内存子系统事务，那么也将破坏原子性。
注：volatile的长整型和双精度浮点型字段和引用始终保证读取和写入的原子性
基于位的设计不是一个理想的解决方案，因为如果64位的异常被删除，那么在32位的体系结构中就会受损。如果在64位架构上行不通，如果期望原 子性，那么不得不为长整型和双精度浮点型引入“volatile”，即使底层硬件可以保证原子操作。例如：volatile类型的字段不需要定义为双精度 浮点型，因为基础架构，或者ISA、浮点单元会处理好64位宽字段的原子性需求。JMM9的目的是确定硬件提供原子性的保证。
JMM-JSR133写于十多年前;此后处理器位数发生了演变，64位已经成为主流的处理位数。当即强调的是，JMM-JSR133提出了针对 64位读写的妥协，尽管64位的值可以由任何架构原子生成，一些架构仍然有必要请求锁。现在，这使得在这些架构上的64位读写操作非常昂贵。在32位 x86架构上，如果不能找到一个合理的原子64位操作实现，则原子性将不会改变。
注：在语言设计中潜在一个问题，关键字“volatile”被赋予了过分的含义。运行时很难弄清楚，用户使用volatile是为了恢复原子性（因此它可以在64位平台被剥离出来），还是为了内存排序的目的。
当谈论访问原子性，读写操作的独立性是要着重考虑的。写入一个特定的字段不应该与读取或者写入其他字段有交互。JMM-JSR133的保证意味 着，同步不应需要提供顺序一致性。因此，JMM-JSR133保证禁止被称为“字分裂”的问题。基本上，当更新一个操作数希望在比基础架构为所有操作数生 成的更低的粒度上操作时，我们将遇到“字撕裂”问题。需要记住的重要一点是，字撕裂问题的原因之一是，64位长整型和双精度浮点型都没有给出原子性保证。 字撕裂在JMM-JSR133中是禁止的，在JMM9中继续保持这种方式。
6. JMM9 - final字段问题
与其他字段相比，final字段是不同的。例如，一个线程用final字段x读取一个“完全初始化”的对象;在对象“完全初始化”后，能保证读取了final字段y的初始值，但不能保证“正常”的非final字段nonX。
注：“完全初始化”是指对象的构造函数完成。
鉴于上述情况，有一些简单的事情可以在JMM9中修复。例如：volatile类型字段，volatile字段在构造函数中初始化是不保证可见 性的，即使对实例本身是可见的。因此，问题来了，是否final字段应该保证扩大到所有字段，包括初始化volatile字段？此外，如果一个完全初始化 对象的“正常”非final字段的值不发生变化，我们是否可以将final字段保证到这个“正常”的字段。