【死磕Java并发】-----Java内存模型之分析volatile

前篇博客【死磕Java并发】—–深入分析volatile的实现原理 中已经阐述了volatile的特性了:

  1. volatile可见性;对一个volatile的读,总可以看到对这个变量最终的写;
  2. volatile原子性;volatile对单个读/写具有原子性(32位Long、Double),但是复合操作除外,例如i++;
  3. JVM底层采用“内存屏障”来实现volatile语义

下面LZ就通过happens-before原则和volatile的内存语义两个方向介绍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原则,就上面程序得到如下关系:

  • 依据happens-before程序顺序原则:1 happens-before 2、3 happens-before 4;
  • 根据happens-before的volatile原则:2 happens-before 3;
  • 根据happens-before的传递性:1 happens-before 4

操作1、操作4存在happens-before关系,那么1一定是对4可见的。可能有同学就会问,操作1、操作2可能会发生重排序啊,会吗?如果看过LZ的博客就会明白,volatile除了保证可见性外,还有就是禁止重排序。所以A线程在写volatile变量之前所有可见的共享变量,在线程B读同一个volatile变量后,将立即变得对线程B可见。

volataile的内存语义及其实现

在JMM中,线程之间的通信采用共享内存来实现的。volatile的内存语义是:

当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量值立即刷新到主内存中。

当读一个volatile变量时,JMM会把该线程对应的本地内存设置为无效,直接从主内存中读取共享变量

所以volatile的写内存语义是直接刷新到主内存中,读的内存语义是直接从主内存中读取。

那么volatile的内存语义是如何实现的呢?对于一般的变量则会被重排序,而对于volatile则不能,这样会影响其内存语义,所以为了实现volatile的内存语义JMM会限制重排序。其重排序规则如下:

翻译如下:

  1. 如果第一个操作为volatile读,则不管第二个操作是啥,都不能重排序。这个操作确保volatile读之后的操作不会被编译器重排序到volatile读之前;
  2. 当第二个操作为volatile写是,则不管第一个操作是啥,都不能重排序。这个操作确保volatile写之前的操作不会被编译器重排序到volatile写之后;
  3. 当第一个操作volatile写,第二操作为volatile读时,不能重排序。

volatile的底层实现是通过插入内存屏障,但是对于编译器来说,发现一个最优布置来最小化插入内存屏障的总数几乎是不可能的,所以,JMM采用了保守策略。如下:

  • 在每一个volatile写操作前面插入一个StoreStore屏障
  • 在每一个volatile写操作后面插入一个StoreLoad屏障
  • 在每一个volatile读操作后面插入一个LoadLoad屏障
  • 在每一个volatile读操作后面插入一个LoadStore屏障

StoreStore屏障可以保证在volatile写之前,其前面的所有普通写操作都已经刷新到主内存中。

StoreLoad屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序。

LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。

LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。

下面我们就上面那个VolatileTest例子分析下:

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:保留

所以2、3、6可以省略,其示意图如下:

参考资料

  1. 方腾飞:《Java并发编程的艺术》
时间: 02-22

【死磕Java并发】-----Java内存模型之分析volatile的相关文章

关于JAVA中的static方法、并发问题以及JAVA运行时内存模型

一.前言 最近在工作上用到了一个静态方法,跟同事交流的时候,被一个问题给问倒了,只怪基础不扎实... 问题大致是这样的,"在多线程环境下,静态方法中的局部变量会不会被其它线程给污染掉?": 我当时的想法:方法中的局部变量在运行的时候,是存在JAVA栈中的,方法运行结束,局部变量也就都弹光了,理论上单线程的话是不会有问题的,我之所以不知道,是因为不清楚在JAVA内存模型中,一个线程对应一个栈,还是多个线程共享一个栈... 其实如果知道每个线程都有一个自己的JAVA栈的话,问题也就很清楚了

全面理解Java内存模型(JMM)及volatile关键字(转)

原文地址:全面理解Java内存模型(JMM)及volatile关键字 关联文章: 深入理解Java类型信息(Class对象)与反射机制 深入理解Java枚举类型(enum) 深入理解Java注解类型(@Annotation) 深入理解Java类加载器(ClassLoader) 深入理解Java并发之synchronized实现原理 Java并发编程-无锁CAS与Unsafe类及其并发包Atomic 深入理解Java内存模型(JMM)及volatile关键字 剖析基于并发AQS的重入锁(Reetr

Java虚拟机:内存模型详解

版权声明:本文为博主原创文章,转载请注明出处,欢迎交流学习! 我们都知道,当虚拟机执行Java代码的时候,首先要把字节码文件加载到内存,那么这些类的信息都存放在内存中的哪个区域呢?当我们创建一个对象实例的时候,虚拟机要为对象分配内存,Java虚拟机又是如何配分内存的呢?这些都涉及到Java虚拟机的内存划分机制,今天我们就来探究一下Java虚拟机的内存模型. Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域,这些区域都有各自的用途以及创建和销毁的时间,有的区域随

进程与线程(二) java进程的内存模型

从我出生那天起,我就知道我有个兄弟,他桀骜不驯,但实力强悍 ,人家都叫它C+++            ----java 上回说到了,C进程的内存分配,那么一个java运行过程也是一个进程,java内存是如何分配的呢? http://blog.csdn.net/shimiso/article/details/8595564 详情请看:http://blog.csdn.net/a859522265/article/details/7282817 1.学习java,学过java多线程,没有学过多进程

java虚拟机之内存模型

1. 概述 对于从事 C.C++ 程序开发的人员来说,在内存管理领域,他们既是拥有最高权力的「皇帝」又是从事基础工作的「劳动人民」 --- 既拥有每个对象的「所有权」,又担负着每一个对象生命开始到终结的维护责任. 但是对于 java 程序员来说,在虚拟机自动内存管理机制的帮助下,不需要再为每一个 new 操作写配对的 delete/free 代码,不容易出现在内存泄漏和内存溢出问题,由虚拟机管理内存这一切看起来都很美好.不过,也正是因为 java 程序员把内存控制的权利交给了 java 虚拟机,

Java并发编程 ReentrantLock 源码分析

ReentrantLock 一个可重入的互斥锁 Lock,它具有与使用 synchronized 方法和语句所访问的隐式监视器锁相同的一些基本行为和语义,但功能更强大. 这个类主要基于AQS(AbstractOwnableSynchronizer)封装的 公平与非公平锁. 所谓公平锁就是指 在多个线程的争用下,这些锁倾向于将访问权授予等待时间最长的线程,换句话说也就是先被锁定的线程首先获得锁. 非公平锁正好相反,解锁时没有固定顺序. 让我们边分析源代码边学习如何使用该类 先来看一下构造参数,默认

Java虚拟机的内存模型

一.问题起源 这篇文章的起源其实是博主想要学习Java并发,计算机并发的痛点在于一方面cpu越来越多核化,另外 一个方面就是cpu和存储以及通信子系统的速度差距太大,大概来说,cpu速度是ns级,内存100ns,硬盘ms,内存比cpu慢100倍, 硬盘比cpu慢100万倍,cpu如果-等这些速度慢的多的小伙伴,势必造成计算资源的浪费.物理机为了解决cpu与内存的速度差, 在两者之间加入了缓存,有缓存就会引入新问题,即缓存一致性问题. 图1(图片来自参考文献[1]) 为了解决缓存一致性问题,各个c

Java并发之内存模型-JMM

1.总括 并发编程模型主要处理两个问题:线程之间如何通信及线程之间如何同步.通信:线程之间以何种机制来交换信息:同步:程序用来控制不同线程之间操作发生相对顺序的机制. 发生线程安全性的时机: 变量存储在内存中,变量的计算是在CUP中.如果线程A要对变量a进行计算,需要经过三步:1)把变量a从内存中读取到CPU中,2)对变量a进行计算,3)把变量a写入到内存中.当线程A执行到第二步时,线程B也要对变量a进行计算,这时B从内存中读取到的值就是线程A写入到内存之前的值,脏数据就此产生了. 在命令式编程

java多线程12.内存模型

假设一个线程为变量赋值:variable = 3: 内存模型需要解决一个问题:"在什么条件下,读取variable的线程将看到这个值为3?" 这看上去理所当然,但是如果缺少内存同步,那么将会有许多因素使得线程无法立即甚至永远,看到另一个线程的操作结果. 如: 1.在编译器中生成的指令顺序,可以与源代码中的顺序不同,此外编译器还会将变量保存在寄存器而不是内存中: 2.处理器可以采用乱序或并行等方式来执行指令: 3.缓存可能会改变将写入变量提交到主内存的次序: 4.而且保存在处理器本地缓存