Java理论与实践: 修复Java内存模型，第1部分

活跃了将近三年的 JSR 133，近期发布了关于如何修复 Java 内存模型 （Java Memory Model, JMM）的公开建议。原始 JMM 中有几个严重缺陷，这导 致了一些难度高得惊人的概念语义，这些概念原来被认为很简单，如 volatile 、final 以及 synchronized。在这一期的 Java 理论与实践 中，Brian Goetz 展示了如何加强 volatile 和 final 的语义，以修复 JMM。这些更改有些已经 集成在 JDK 1.4 中；而另一些将会包含在 JDK 1.5 中。

Java 平台把线程和多处理技术集成到了语言中，这种集成程度比以前的大多 数编程语言都要强很多。该语言对于平台独立的并发及多线程技术的支持是野心 勃勃并且是具有开拓性的，或许并不奇怪，这个问题要比 Java 体系结构设计者 的原始构想要稍微困难些。关于同步和线程安全的许多底层混淆是 Java 内存模 型 (JMM)的一些难以直觉到的细微差别，这些差别最初是在 Java Language Specification 的第 17 章中指定的，并且由 JSR 133 重新指定。

例如，并不是所有的多处理器系统都表现出 缓存一致性（cache coherency ）；假如有一个处理器有一个更新了的变量值位于其缓存中，但还没有被存入主 存，这样别的处理器就可能会看不到这个更新的值。在缓存缺乏一致性的情况下 ，两个不同的处理器可以看到在内存中同一位置处有两种不同的值。这听起来不 太可能，但是这却是故意的 —— 这是一种获得较高的性能和可伸缩性的方法 —— 但是这加重了开发者和编译器为解决这些问题而编写代码的负担。

什么是内存模型，我为什么需要一个内存模型？

内存模型描述的是程序中各变量（实例域、静态域和数组元素）之间的关系 ，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节 。对象最终存储在内存中，但编译器、运行库、处理器或缓存可以有特权定时地 在变量的指定内存位置存入或取出变量值。例如，编译器为了优化一个循环索引 变量，可能会选择把它存储到一个寄存器中，或者缓存会延迟到一个更适合的时 间，才把一个新的变量值存入主存。所有的这些优化是为了帮助实现更高的性能 ，通常这对于用户来说是透明的，但是对多处理系统来说，这些复杂的事情可能 有时会完全显现出来。

JMM 允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存之间 移动的次序拥有重要的特权，除非程序员已经使用 synchronized 或 final 明 确地请求了某些可见性保证。这意味着在缺乏同步的情况下，从不同的线程角度 来看，内存的操作是以不同的次序发生的。

与之相对应地，像 C 和 C++ 这些语言就没有显示的内存模型 —— 但 C 语 言程序继承了执行程序处理器的内存模型（尽管一个给定体系结构的编译器可能 知道有关底层处理器的内存模型的一些情况，并且保持一致性的一部分责任也落 到了该编译器的头上）。这意味着并发的 C 语言程序可以在一个，而不能在另 一个，处理器体系结构上正确地运行。虽然一开始 JMM 会有些混乱，但这有个 很大的好处 —— 根据 JMM 而被正确同步的程序能正确地运行在任何支持 Java 的平台上。

原始 JMM 的缺点

虽然在 Java Language Specification 的第 17 章指定的 JMM 是一个野心 勃勃的尝试，它尝试定义一个一致的、跨平台的内存模型，但它有一些细微而重 要的缺点。 synchronized 和 volatile 的语义很让人混淆，以致于许多有见地 的开发者有时选择忽略这些规则，因为在旧的存储模型下编写正确同步的代码非 常困难。

旧的 JMM 允许一些奇怪而混乱的事情发生，比如 final 字段看起来没有那 种设置在构造函数里的值（这样使得想像上的不可变对象

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!