Java 线程/内存模型的缺陷和增强

     本文是由JR主持写作的《J2SE进阶》一书的部分章节整理而成，《J2SE进阶》正在写作、完善阶段。您阅读后，有任何建议、批评，请 和我联系 ，或在 这儿留言 。《J2SE进阶》写作项目组感谢您阅读本文。


     java在语言层次上实现了对线程的支持。它提供了Thread/Runnable/ThreadGroup等一系列封装的类和接口，让程序员可以高效的开发Java多线程应用。为了实现同步，Java提供了synchronize要害字以及object的wait()/notify()机制，可是在简单易用的背后，应藏着更为复杂的玄机，很多问题就是由此而起。

一、Java内存模型

在了解Java的同步秘密之前，先来看看JMM(Java Memory Model)。
Java被设计为跨平台的语言，在内存治理上，显然也要有一个统一的模型。而且Java语言最大的特点就是废除了指针，把程序员从痛苦中解脱出来，不用再考虑内存使用和治理方面的问题。
可惜世事总不尽如人意，虽然JMM设计上方便了程序员，但是它增加了虚拟机的复杂程度，而且还导致某些编程技巧在Java语言中失效。

JMM主要是为了规定了线程和内存之间的一些关系。对Java程序员来说只需负责用synchronized同步要害字，其它诸如与线程/内存之间进行数据交换/同步等繁琐工作均由虚拟机负责完成。如图1所示：根据JMM的设计，系统存在一个主内存(Main Memory)，Java中所有变量都储存在主存中，对于所有线程都是共享的。每条线程都有自己的工作内存(Working Memory)，工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作都是在工作内存中进行，线程之间无法相互直接访问，变量传递均需要通过主存完成。

图1 Java内存模型示例图

线程若要对某变量进行操作，必须经过一系列步骤：首先从主存复制/刷新数据到工作内存，然后执行代码，进行引用/赋值操作，最后把变量内容写回Main Memory。Java语言规范(JLS)中对线程和主存互操作定义了6个行为，分别为load，save，read，write，assign和use，这些操作行为具有原子性，且相互依靠，有明确的调用先后顺序。具体的描述请参见JLS第17章。

我们在前面的章节介绍了synchronized的作用，现在，从JMM的角度来重新审阅synchronized要害字。
假设某条线程执行一个synchronized代码段，其间对某变量进行操作，JVM会依次执行如下动作：
(1) 获取同步对象monitor (lock)
(2) 从主存复制变量到当前工作内存 (read and load)
(3) 执行代码，改变共享变量值 (use and assign)
(4) 用工作内存数据刷新主存相关内容 (store and write)
(5) 释放同步对象锁 (unlock)
可见，synchronized的另外一个作用是保证主存内容和线程的工作内存中的数据的一致性。假如没有使用synchronized要害字，JVM不保证第2步和第4步会严格按照上述次序立即执行。因为根据JLS中的规定，线程的工作内存和主存之间的数据交换是松耦合的，什么时候需要刷新工作内存或者更新主内存内容，可以由具体的虚拟机实现自行决定。假如多个线程同时执行一段未经synchronized保护的代码段，很有可能某条线程已经改动了变量的值，但是其他线程却无法看到这个改动，依然在旧的变量值上进行运算，最终导致不可预料的运算结果。

二、DCL失效

这一节我们要讨论的是一个让Java丢脸的话题：DCL失效。在开始讨论之前，先介绍一下LazyLoad，这种技巧很常用，就是指一个类包含某个成员变量，在类初始化的时候并不立即为该变量初始化一个实例，而是等到真正要使用到该变量的时候才初始化之。
例如下面的代码：
代码1

由于LazyLoad可以有效的减少系统资源消耗，提高程序整体的性能，所以被广泛的使用，连Java的缺省类加载器也采用这种方法来加载Java类。
在单线程环境下，一切都相安无事，但假如把上面的代码放到多线程环境下运行，那么就可能会出现问题。假设有2条线程，同时执行到了if(res == null)，那么很有可能res被初始化2次，为了避免这样的Race Condition，得用synchronized要害字把上面的方法同步起来。代码如下：
代码2