Java 理论与实践: 修复 Java 内存模型，第 2 部分 （VOLATILE， FINA...

活跃了将近三年的 JSR 133，近期发布了关于如何修复 Java 内存模型（Java Memory Model, JMM）的公开建议。在本系列文章的 第 1 部分，专栏做者 Brian Goetz 主要介绍最初的 JMM 中的几个严重缺陷，这些缺陷致使了一些难度高得惊人的概念语义，这些概念原来被认为很简单。这个月，他介绍在新 JMM 中 volatile 和 final 的语义是如何变化的，这些改变使它们的语义符合大多数开发人员的直觉。其中一些改变已经在 JDK 1.4 中出现了，另外一些改变则要等到 JDK 1.5。请您在本文的讨论论坛上与做者及其余读者交流您的想法。

开始编写并发代码是一件困难的事情，语言不该当增长它的难度。虽然 Java 平台从一开始就包括了对线程的支持，包括一个计划为正确同步的程序提供“一次编写，处处运行”保证的、跨平台的内存模型，可是原来的内存模型有一些漏洞。虽然许多 Java 平台提供了比 JMM 所要求的更强的保证，可是 JMM 中的漏洞使得没法容易地编写能够在任何平台上运行的并发 Java 程序。因此在 2001 年 5 月，成立了以修复 Java 内存模型为目的的 JSR 133。 上个月，我讨论了其中一些漏洞，这个月，咱们将讨论如何堵住它们。

修复后的可见性

理解 JMM 所须要的一个关键概念是 可见性（visibility）——如何知道当线程 A 执行 someVariable?=?3 时，其余线程是否能够看到线程 A 所写的值 3？有一些缘由使其余线程不能当即看到 someVariable 的值 3：多是由于编译器为了执行效率更高而从新排序了指令，也多是 someVariable 缓存在寄存器中，或者它的值写到写处理器的缓存中、可是尚未刷新到主存中，或者在读处理器的缓存中有一个老的（或者无效的）值。内存模型决定何时一个线程能够可靠地“看到”由其余线程对变量的写入。特别是，内存模型定义了保证内存操做跨线程的可见性的 volatile 、 synchronized 和 final 的语义