Java内存模型的基础
本文是《java并发编程的艺术》一书的学习笔记
1.Java内存模型的抽象结构
1.Java线程之间的通讯由Java内存模型(JMM)控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。
2.线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存存储了该线程以读/写共享变量的副本。本地内存是一个抽象概念，并不真实存在。
3.Java内存模型的抽象示意图如下
如果线程A与线程B之间要通讯的话，需要经历下面两个步骤。
- 1.线程A把本地内存A中更新的共享变量刷新到主内存中去。
- 2.线程B到主内存中去读取线程A之前已更新过的共享变量。
2.happens-before简介
1.从JDK5开始，Java使用新的JSR-133内存模型。JSR-133使用happens-before的概念来阐述操作之间的内存可见性。
2.在JMM中如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。这里的操作既可以是在一个线程内，也可以在不同线程之间。
3.与程序员密切相关的happens-before规则如下
- 程序顺序规则:一个线程中的每个操作，happens-before于该线程中的任意后续操作。
- 监视器锁规则:对一个锁的解锁，happens-before于随后对这个锁加锁。
- volatile变量规则:对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
- 传递性:如果 A happens-before B, 且 B happens-before C,那么 A happens-before C.
注意
两个操作之间具有happens-before关系，并不意味着前一个操作必须要在后一个操作之前执行！ happens-before仅仅要求前一个操作(执行的结果)对后一个操作可见，且前一个操作按顺序排在第二个操作之前
happens-before与JMM的关系如下：
Volatile内存语义
Volatile的特性
理解volatile特性的一个方法是把对volatile变量的单个读/写，看成是使用同一个锁对这个读/写做了同步。下面通过具体示例说明：
假设有多个线程分别调用上面程序的3个方法，这个程序在语义上和下面的程序等价
如上面的程序所示，一个volatile变量的单个读/写操作，与一个普通变量的读/写操作是使用同一个锁来同步，它们之间的执行效果相同。
volatile具有以下特性
- 可见性。 当线程A对volatile变量写入时，该变量会刷新到主内存。然后当线程B读取该volatile变量时，会在主内存中进行读取，避免在自身的本地线程读取。 对一个volatile变量的读，总是能看到(任意线程)对这个volatile变量最后的写入。
- 原子性。 对任意单个volatile变量的读/写具有原子性，但类似volatile++这种复合操作不具有原子性。
- 禁止编译器处理器指令重排序。 严格限制编译器处理器对volatile变量与普通变量的重排序，确保volatile的读/写和锁的释放/获取具有相同的内存语义。
volatile内存语义的实现
为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
下面是基于保守策略的JMM内存屏障插入策略。
- 在每个volatile写操作的前面插入一个StoreStore屏障
- 在每个volatile写操作的后面插入一个StoreLoad屏障
- 在每个volatile读操作的后面插入一个LoadLoad屏障
- 在每个volatile读操作的后面插入一个LoadStore屏障
锁的内存语义
1.当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中
2.当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使被监视器保护的临界区代码必须从主内存中读取共享变量。
final域的内存语义
1.通过为final域增加读写重排序规则，可以为java程序员提供初始化安全保证：
只要对象是正确构造的(被构造对象的引用在构造函数中没有“逸出”)，那么不需要使用同步(指lock和volatile的使用)就可以保证任意线程都能看到这个final域在构造函数中被初始化之后的值
2.为什么final引用不能从构造函数内"逸出"？
看下示例代码：
假设线程A执行writer()方法，线程B执行reader()方法。这里的操作2使得对象还未完成构造前就为线程B可见。即使这里的操作2是构造函数的最后一步，且在程序中操作2排在操作1后面，执行read()方法的线程仍然可能无法看到final域被初始化后的值，因为这里的操作1和操作2可能被重排序。
双重检查锁定与延迟初始化
双重检查锁定的由来
下面是示例代码
上面的代码是有问题的，问题的根源在第7行初始化的时候。
因为初始化构造的时候会存在重排序
new DclSinglenton()初始化构造的时候可以分解如下三行伪代码：
memory = allocate(); //1.分配对象的内存空间
ctorInstance(memory);//2.初始化对象
instance = memory;//3.设置instance指向刚分配的内存地址
多线程情况下2，3可能会重排序，如下：
memory = allocate(); //1.分配对象的内存空间
instance = memory;//3.设置instance指向刚分配的内存地址
//注意，此时对象还没有被初始化
ctorInstance(memory);//2.初始化对象
第7行如果发生重排序，另一个并发执行的线程B就有可能在第4行判断instance不为null. 线程B接下来将访问instance所引用的对象，但此时这个对象可能还没有被A线程初始化！
解决方法：
1.不允许2和3重排序
2.允许2和3重排序，但不允许其他线程”看到“这个重排序。
基于volatile的解决方案
public class SafeDoubleCheckedLocking{
private volatile static Instance instance;//声明volatile
public static Instance getInstance(){
if (instance == null){
synchronized (SafeDoubleCheckedLocking.class){
if (instance == null){
instance = new Instance(); //没有问题
}
}
}
}
}
声明对象的引用为volatile后，禁止伪代码中的2，3重排序
基于类初始化的解决方案
JVM在类的初始化阶段(即在Class被加载后，且被线程使用之前)，会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。
基于这个特性，可以实现另一种线程安全的延迟初始化方案
public class StaticInnerSingleton {
private StaticInnerSingleton() {
}
public static StaticInnerSingleton getInstance() {
return SingletonHolder.sInstance;
}
// 静态内部类
private static class SingletonHolder {
private static final StaticInnerSingleton sInstance = new StaticInnerSingleton();
}
}
参考：
《java并发编程的艺术》
