注：数据竞态可能产生推测的结果，这将最终把自己变成自我实现的预言。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字段问题