JMM-JSR133写于十多年前;此后处理器位数发生了演变，64位已经成为主流的处理位数。当即强调的是，JMM-JSR133提出了针对64位读写的妥协，尽管64位的值可以由任何架构原子生成，一些架构仍然有必要请求锁。现在，这使得在这些架构上的64位读写操作非常昂贵。在32位x86架构上，如果不能找到一个合理的原子64位操作实现，则原子性将不会改变。

注：在语言设计中潜在一个问题，关键字“volatile”被赋予了过分的含义。运行时很难弄清楚，用户使用volatile是为了恢复原子性（因此它可以在64位平台被剥离出来），还是为了内存排序的目的。

当谈论访问原子性，读写操作的独立性是要着重考虑的。写入一个特定的字段不应该与读取或者写入其他字段有交互。JMM-JSR133的保证意味着，同步不应需要提供顺序一致性。因此，JMM-JSR133保证禁止被称为“字分裂”的问题。基本上，当更新一个操作数希望在比基础架构为所有操作数生成的更低的粒度上操作时，我们将遇到“字撕裂”问题。需要记住的重要一点是，字撕裂问题的原因之一是，64位长整型和双精度浮点型都没有给出原子性保证。字撕裂在JMM-JSR133中是禁止的，在JMM9中继续保持这种方式。

与其他字段相比，final字段是不同的。例如，一个线程用final字段x读取一个“完全初始化”的对象;在对象“完全初始化”后，能??证读取了final字段y的初始值，但不能保证“正常”的非final字段nonX。

注：“完全初始化”是指对象的构造函数完成。

鉴于上述情况，有一些简单的事情可以在JMM9中修复。例如：volatile类型字段，volatile字段在构造函数中初始化是不保证可见性的，即使对实例本身是可见的。因此，问题来了，是否final字段应该保证扩大到所有字段，包括初始化volatile字段？此外，如果一个完全初始化对象的“正常”非final字段的值不发生变化，我们是否可以将final字段保证到这个“正常”的字段。

我从如下这些网站学到了很多，他们提供了大量的示例编码。本文是一篇介绍性的文章，以下文章更适合深入掌握Java内存模型。

感谢Jeremy Manson，帮助我纠正了很多误解，并为我更清楚地解释了那些对于我来说很新的术语。还要感谢Aleksey Shipilev，帮助我减少了本文草稿版本中出现的概念的复杂性。Aleksey还指导我们去他的JMM，语用学文章更深层次的理解，澄清和例子。