【死磕Java并发】—–Java内存模型
【死磕Java并发】—–Java内存模型之happens-before
原文出处：http://cmsblogs.com/ 『chenssy』
在上篇博客（【死磕Java并发】-----深入分析volatile的实现原理）LZ提到过由于存在线程本地内存和主内存的原因，再加上重排序，会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下，线程A修改了变量a何时对线程B可见？ 我们无法就所有场景来规定某个线程修改的变量何时对其他线程可见，但是我们可以指定某些规则，这规则就是happens-before，从JDK 5 开始，JMM就使用happens-before的概念来阐述多线程之间的内存可见性。
在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。happens-before原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。下面我们就一个简单的例子稍微了解下happens-before ；
i = 1; //线程A执行
j = i ; //线程B执行- 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；
- 锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作；
- volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；
- 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C；
- 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；
- 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；
- 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；
- 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始；
- 程序次序规则：一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序（重排序后面会详细介绍）。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。
- volatile变量规则：这是一条比较重要的规则，它标志着volatile保证了线程可见性。通俗点讲就是如果一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作一定是happens-before读操作的。
- 传递规则：提现了happens-before原则具有传递性，即A happens-before B , B happens-before C，那么A happens-before C
- 线程启动规则：假定线程A在执行过程中，通过执行ThreadB.start()来启动线程B，那么线程A对共享变量的修改在接下来线程B开始执行后确保对线程B可见。
- 线程终结规则：假定线程A在执行的过程中，通过制定ThreadB.join()等待线程B终止，那么线程B在终止之前对共享变量的修改在线程A等待返回后可见。
- 将一个元素放入一个线程安全的队列的操作Happens-Before从队列中取出这个元素的操作
- 将一个元素放入一个线程安全容器的操作Happens-Before从容器中取出这个元素的操作
- 在CountDownLatch上的倒数操作Happens-Before CountDownLatch#await()操作
- 释放Semaphore许可的操作Happens-Before获得许可操作
- Future表示的任务的所有操作Happens-Before Future#get()操作
- 向Executor提交一个Runnable或Callable的操作Happens-Before任务开始执行操作
private int i = 0;
public void write(int j ){
i = j;
}
public int read(){
return i;
}- 由于两个方法是由不同的线程调用，所以肯定不满足程序次序规则；
- 两个方法都没有使用锁，所以不满足锁定规则；
- 变量i不是用volatile修饰的，所以volatile变量规则不满足；
- 传递规则肯定不满足；
happen-before原则是JMM中非常重要的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。下图是happens-before与JMM的关系图（摘自《Java并发编程的艺术》）
参考资料
- 周志明：《深入理解Java虚拟机》
- 方腾飞：《Java并发编程的艺术》
【死磕Java并发】—–Java内存模型之重排序
免费领取10G资料包与项目实战视频资料 原文出处：http://cmsblogs.com/ 『chenssy』
在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：- 在单线程环境下不能改变程序运行的结果；
- 存在数据依赖关系的不允许重排序
as-if-serial语义
as-if-serial语义的意思是，所有的操作均可以为了优化而被重排序，但是你必须要保证重排序后执行的结果不能被改变，编译器、runtime、处理器都必须遵守as-if-serial语义。注意as-if-serial只保证单线程环境，多线程环境下无效。 下面我们用一个简单的示例来说明：int a = 1 ; //A int b = 2 ; //B int c = a + b; //C- A happens-before B
- B happens-before C
- A happens-before C
public class RecordExample1 { public static void main(String[] args){ int a = 1; int b = 2; try { a = 3; //A b = 1 / 0; //B } catch (Exception e) { } finally { System.out.println("a = " + a); } } }重排序对多线程的影响
在单线程环境下由于as-if-serial语义，重排序无法影响最终的结果，但是对于多线程环境呢？ 如下代码（volatile的经典用法）：public class RecordExample2 { int a = 0; boolean flag = false; /** * A线程执行 */ public void writer(){ a = 1; // 1 flag = true; // 2 } /** * B线程执行 */ public void read(){ if(flag){ // 3 int i = a + a; // 4 } } }
按照这种执行顺序线程B肯定读不到线程A设置的a值，在这里多线程的语义就已经被重排序破坏了。 操作3 和操作4 之间也可以重排序，这里就不阐述了。但是他们之间存在一个控制依赖的关系，因为只有操作3 成立操作4 才会执行。当代码中存在控制依赖性时，会影响指令序列的执行的并行度，所以编译器和处理器会采用猜测执行来克服控制依赖对并行度的影响。假如操作3 和操作4重排序了，操作4 先执行，则先会把计算结果临时保存到重排序缓冲中，当操作3 为真时才会将计算结果写入变量i中 通过上面的分析，重排序不会影响单线程环境的执行结果，但是会破坏多线程的执行语义。【死磕Java并发】—–Java内存模型之分析volatile
免费领取10G资料包与项目实战视频资料 原文出处：http://cmsblogs.com/ 『chenssy』
前篇博客【死磕Java并发】-----深入分析volatile的实现原理 中已经阐述了volatile的特性了：- volatile可见性；对一个volatile的读，总可以看到对这个变量最终的写；
- volatile原子性；volatile对单个读/写具有原子性（32位Long、Double），但是复合操作除外，例如i++;
- JVM底层采用“内存屏障”来实现volatile语义
volatile与happens-before
在这篇博客【死磕Java并发】-----Java内存模型之happend-before中LZ阐述了happens-before是用来判断是否存数据竞争、线程是否安全的主要依据，它保证了多线程环境下的可见性。下面我们就那个经典的例子来分析volatile变量的读写建立的happens-before关系。public class VolatileTest { int i = 0; volatile boolean flag = false; //Thread A public void write(){ i = 2; //1 flag = true; //2 } //Thread B public void read(){ if(flag){ //3 System.out.println("---i = " + i); //4 } } }- 依据happens-before程序顺序原则：1 happens-before 2、3 happens-before 4；
- 根据happens-before的volatile原则：2 happens-before 3；
- 根据happens-before的传递性：1 happens-before 4
volataile的内存语义及其实现
在JMM中，线程之间的通信采用共享内存来实现的。volatile的内存语义是：当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新到主内存中。 当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，直接从主内存中读取共享变量
所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取。 那么volatile的内存语义是如何实现的呢？对于一般的变量则会被重排序，而对于volatile则不能，这样会影响其内存语义，所以为了实现volatile的内存语义JMM会限制重排序。其重排序规则如下： 翻译如下：- 如果第一个操作为volatile读，则不管第二个操作是啥，都不能重排序。这个操作确保volatile读之后的操作不会被编译器重排序到volatile读之前；
- 当第二个操作为volatile写是，则不管第一个操作是啥，都不能重排序。这个操作确保volatile写之前的操作不会被编译器重排序到volatile写之后；
- 当第一个操作volatile写，第二操作为volatile读时，不能重排序。
- 在每一个volatile写操作前面插入一个StoreStore屏障
- 在每一个volatile写操作后面插入一个StoreLoad屏障
- 在每一个volatile读操作后面插入一个LoadLoad屏障
- 在每一个volatile读操作后面插入一个LoadStore屏障
public class VolatileTest { int i = 0; volatile boolean flag = false; public void write(){ i = 2; flag = true; } public void read(){ if(flag){ System.out.println("---i = " + i); } } }
上面通过一个例子稍微演示了volatile指令的内存屏障图例。 volatile的内存屏障插入策略非常保守，其实在实际中，只要不改变volatile写-读得内存语义，编译器可以根据具体情况优化，省略不必要的屏障。如下（摘自方腾飞 《Java并发编程的艺术》）：
public class VolatileBarrierExample { int a = 0; volatile int v1 = 1; volatile int v2 = 2; void readAndWrite(){ int i = v1; //volatile读 int j = v2; //volatile读 a = i + j; //普通读 v1 = i + 1; //volatile写 v2 = j * 2; //volatile写 } }
我们来分析上图有哪些内存屏障指令是多余的
- 1：这个肯定要保留了
- 2：禁止下面所有的普通写与上面的volatile读重排序，但是由于存在第二个volatile读，那个普通的读根本无法越过第二个volatile读。所以可以省略。
- 3：下面已经不存在普通读了，可以省略。
- 4：保留
- 5：保留
- 6：下面跟着一个volatile写，所以可以省略
- 7：保留
- 8：保留
参考资料
- 方腾飞：《Java并发编程的艺术》
【死磕Java并发】—–Java内存模型之从JMM角度分析DCL
免费领取10G资料包与项目实战视频资料 原文出处：http://cmsblogs.com/ 『chenssy』
DCL，即Double Check Lock，中卫双重检查锁定。其实DCL很多人在单例模式中用过，LZ面试人的时候也要他们写过，但是有很多人都会写错。他们为什么会写错呢？其错误根源在哪里？有什么解决方案？下面就随LZ一起来分析问题分析
我们先看单例模式里面的懒汉式：
我们都知道这种写法是错误的，因为它无法保证线程的安全性。优化如下：public class Singleton { private static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ singleton = new Singleton(); } return singleton; } }
优化非常简单，就是在getInstance方法上面做了同步，但是synchronized就会导致这个方法比较低效，导致程序性能下降，那么怎么解决呢？聪明的人们想到了双重检查 DCL：public class Singleton { private static Singleton singleton; private Singleton(){} public static synchronized Singleton getInstance(){ if(singleton == null){ singleton = new Singleton(); } return singleton; } }
就如上面所示，这个代码看起来很完美，理由如下：public class Singleton { private static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ // 1 synchronized (Singleton.class){ // 2 if(singleton == null){ // 3 singleton = new Singleton(); // 4 } } } return singleton; } }- 如果检查第一个singleton不为null,则不需要执行下面的加锁动作，极大提高了程序的性能；
- 如果第一个singleton为null,即使有多个线程同一时间判断，但是由于synchronized的存在，只会有一个线程能够创建对象；
- 当第一个获取锁的线程创建完成后singleton对象后，其他的在第二次判断singleton一定不会为null，则直接返回已经创建好的singleton对象；
- 分配内存空间
- 初始化对象
- 将内存空间的地址赋值给对应的引用
- 分配内存空间
- 将内存空间的地址赋值给对应的引用
- 初始化对象
按照上面图例所示，线程B访问的是一个没有被初始化的singleton对象。 通过上面的阐述，我们可以判断DCL的错误根源在于步骤4：
知道问题根源所在，那么怎么解决呢？有两个解决办法：singleton = new Singleton();- 不允许初始化阶段步骤2 、3发生重排序。
- 允许初始化阶段步骤2 、3发生重排序，但是不允许其他线程“看到”这个重排序。
解决方案
解决方案依据上面两个解决办法即可。基于volatile解决方案
对于上面的DCL其实只需要做一点点修改即可：将变量singleton生命为volatile即可：
当singleton声明为volatile后，步骤2、步骤3就不会被重排序了，也就可以解决上面那问题了。public class Singleton { //通过volatile关键字来确保安全 private volatile static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ synchronized (Singleton.class){ if(singleton == null){ singleton = new Singleton(); } } } return singleton; } }基于类初始化的解决方案
该解决方案的根本就在于：利用classloder的机制来保证初始化instance时只有一个线程。JVM在类初始化阶段会获取一个锁，这个锁可以同步多个线程对同一个类的初始化。
这种解决方案的实质是：运行步骤2和步骤3重排序，但是不允许其他线程看见。public class Singleton { private static class SingletonHolder{ public static Singleton singleton = new Singleton(); } public static Singleton getInstance(){ return SingletonHolder.singleton; } }Java语言规定，对于每一个类或者接口C,都有一个唯一的初始化锁LC与之相对应。从C到LC的映射，由JVM的具体实现去自由实现。JVM在类初始化阶段期间会获取这个初始化锁，并且每一个线程至少获取一次锁来确保这个类已经被初始化过了。
参考资料
- 方腾飞：《Java并发编程的艺术》
【死磕Java并发】—–Java内存模型之从JMM角度分析DCL
免费领取10G资料包与项目实战视频资料 原文出处：http://cmsblogs.com/ 『chenssy』
DCL，即Double Check Lock，中卫双重检查锁定。其实DCL很多人在单例模式中用过，LZ面试人的时候也要他们写过，但是有很多人都会写错。他们为什么会写错呢？其错误根源在哪里？有什么解决方案？下面就随LZ一起来分析问题分析
我们先看单例模式里面的懒汉式：
我们都知道这种写法是错误的，因为它无法保证线程的安全性。优化如下：public class Singleton { private static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ singleton = new Singleton(); } return singleton; } }
优化非常简单，就是在getInstance方法上面做了同步，但是synchronized就会导致这个方法比较低效，导致程序性能下降，那么怎么解决呢？聪明的人们想到了双重检查 DCL：public class Singleton { private static Singleton singleton; private Singleton(){} public static synchronized Singleton getInstance(){ if(singleton == null){ singleton = new Singleton(); } return singleton; } }
就如上面所示，这个代码看起来很完美，理由如下：public class Singleton { private static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ // 1 synchronized (Singleton.class){ // 2 if(singleton == null){ // 3 singleton = new Singleton(); // 4 } } } return singleton; } }- 如果检查第一个singleton不为null,则不需要执行下面的加锁动作，极大提高了程序的性能；
- 如果第一个singleton为null,即使有多个线程同一时间判断，但是由于synchronized的存在，只会有一个线程能够创建对象；
- 当第一个获取锁的线程创建完成后singleton对象后，其他的在第二次判断singleton一定不会为null，则直接返回已经创建好的singleton对象；
- 分配内存空间
- 初始化对象
- 将内存空间的地址赋值给对应的引用
- 分配内存空间
- 将内存空间的地址赋值给对应的引用
- 初始化对象
按照上面图例所示，线程B访问的是一个没有被初始化的singleton对象。 通过上面的阐述，我们可以判断DCL的错误根源在于步骤4：
知道问题根源所在，那么怎么解决呢？有两个解决办法：singleton = new Singleton();- 不允许初始化阶段步骤2 、3发生重排序。
- 允许初始化阶段步骤2 、3发生重排序，但是不允许其他线程“看到”这个重排序。
解决方案
解决方案依据上面两个解决办法即可。基于volatile解决方案
对于上面的DCL其实只需要做一点点修改即可：将变量singleton生命为volatile即可：
当singleton声明为volatile后，步骤2、步骤3就不会被重排序了，也就可以解决上面那问题了。public class Singleton { //通过volatile关键字来确保安全 private volatile static Singleton singleton; private Singleton(){} public static Singleton getInstance(){ if(singleton == null){ synchronized (Singleton.class){ if(singleton == null){ singleton = new Singleton(); } } } return singleton; } }基于类初始化的解决方案
该解决方案的根本就在于：利用classloder的机制来保证初始化instance时只有一个线程。JVM在类初始化阶段会获取一个锁，这个锁可以同步多个线程对同一个类的初始化。
这种解决方案的实质是：运行步骤2和步骤3重排序，但是不允许其他线程看见。public class Singleton { private static class SingletonHolder{ public static Singleton singleton = new Singleton(); } public static Singleton getInstance(){ return SingletonHolder.singleton; } }Java语言规定，对于每一个类或者接口C,都有一个唯一的初始化锁LC与之相对应。从C到LC的映射，由JVM的具体实现去自由实现。JVM在类初始化阶段期间会获取这个初始化锁，并且每一个线程至少获取一次锁来确保这个类已经被初始化过了。
参考资料
- 方腾飞：《Java并发编程的艺术》
浙公网安备 33010602011771号