JAVA 线程安全三要素

 

(转载)

1 . 原子性(Atomicity)

 Java中,对基本数据类型的读取和赋值操作是原子性操作,所谓原子性操作就是指这些操作是不可中断的,要做一定做完,要么就没有执行。

比如:

i = 2; //原子
j = i; //非原子 (1 读i,2 赋值j)
i++;   //非原子 (1 读i,2 +1 ,3 赋值i
i = i + 1//非原子 (1 读i,2 +1 ,3 赋值i

上面4个操作中,i=2是读取操作,必定是原子性操作,j=i你以为是原子性操作,其实吧,分为两步,一是读取i的值,然后再赋值给j,这就是2步操作了,称不上原子操作,i++i = i + 1其实是等效的,读取i的值,加1,再写回主存,那就是3步操作了。所以上面的举例中,最后的值可能出现多种情况,就是因为满足不了原子性。

这么说来,只有简单的读取,赋值是原子操作,还只能是用数字赋值,用变量的话还多了一步读取变量值的操作。有个例外是,虚拟机规范中允许对64位数据类型(long和double),分为2次32为的操作来处理,但是最新JDK实现还是实现了原子操作的。

JMM只实现了基本的原子性,像上面i++那样的操作,必须借助于synchronizedLock来保证整块代码的原子性了。线程在释放锁之前,其他线程不能取得锁,释放锁时必然会把i的值刷回到主存的。

除了上锁还有CAS操作同样保证原子性。

2 . 可见性(Visibility)

JMM中每一个线程都有自己的独立工作内存区,还有一个公共内存区(主内存)。线程执行时先把变量值从主内存拷贝到自己工作内存区中。可见性的目的就是保证一个线程改变了变量后,其他线程及时刷新自己的工作区内存获取最新值。


Java就是利用volatile来提供可见性的。当一个变量被volatile修饰时,对它的修改会立刻刷新到主存,并将其他线程缓存中的此变量清空,当其它线程需要读取该变量时,会去主内存中读取新值。而普通变量则不能保证每次都去主内存读取到最新值,会有延迟。

其实通过synchronized和Lock也能够保证可见性,线程在释放锁之前,会把变量值都刷回主存,且在持锁后首先从主内存同步所有工作内存变量,但是和Lock的开销都更大。

锁示例:this.isBegin即使不在同步代码块中,在线程下次持有锁时,也会用主内存读取this.isBegin的值,即线程刷新自己的工作区内存。

while(this.isBegin){
    synchronized(o){
      ...
    }
}

3 . 有序性(Ordering)

lock/unlock, volatile关键字可以产生内存屏障,防止指令重排序时越过

JMM是允许编译器和处理器对指令重排序的,但是规定了as-if-serial语义,即不管怎么重排序,程序的执行结果不能改变。比如下面的程序段:

double pi = 3.14;    //A
double r = 1;        //B
double s= pi * r * r;//C

上面的语句,可以按照A->B->C执行,结果为3.14,但是也可以按照B->A->C的顺序执行,因为A、B是两句独立的语句,而C则依赖于A、B,所以A、B可以重排序,但是C却不能排到A、B的前面。JMM保证了重排序不会影响到单线程的执行,但是在多线程中却容易出问题。

比如这样的代码:

int a = 0;
bool flag = false;

public void write() {
    a = 2;              //1
    flag = true;        //2
}

public void multiply() {
    if (flag) {         //3
        int ret = a * a;//4
    }
    
}

假如有两个线程执行上述代码段,线程1先执行write,随后线程2再执行multiply,最后ret的值一定是4吗?结果不一定:

 

如图所示,write方法里的1和2做了重排序,线程1先对flag赋值为true,随后执行到线程2,ret直接计算出结果,再到线程1,这时候a才赋值为2,很明显迟了一步。

 

这时候可以为flag加上volatile关键字,禁止重排序,可以确保程序的“有序性”,也可以上重量级的synchronized和Lock来保证有序性,它们能保证那一块区域里的代码都是一次性执行完毕的。

另外,JMM具备一些先天的有序性,即不需要通过任何手段就可以保证的有序性,通常称为happens-before原则。<<JSR-133:Java Memory Model and Thread Specification>>定义了如下happens-before规则:

  1. 程序顺序规则: 一个线程中的每个操作,happens-before于该线程中的任意后续操作
  2. 监视器锁规则:对一个线程的解锁,happens-before于随后对这个线程的加锁
  3. volatile变量规则: 对一个volatile域的写,happens-before于后续对这个volatile域的读
  4. 传递性:如果A happens-before B ,且 B happens-before C, 那么 A happens-before C
  5. start()规则: 如果线程A执行操作ThreadB_start()(启动线程B) , 那么A线程的ThreadB_start()happens-before 于B中的任意操作
  6. join()原则: 如果A执行ThreadB.join()并且成功返回,那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。
  7. interrupt()原则: 对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生,可以通过Thread.interrupted()方法检测是否有中断发生
  8. finalize()原则:一个对象的初始化完成先行发生于它的finalize()方法的开始

第1条规则程序顺序规则是说在一个线程里,所有的操作都是按顺序的,但是在JMM里其实只要执行结果一样,是允许重排序的,这边的happens-before强调的重点也是单线程执行结果的正确性,但是无法保证多线程也是如此。

第2条规则监视器规则其实也好理解,就是在加锁之前,确定这个锁之前已经被释放了,才能继续加锁。

第3条规则,就适用到所讨论的volatile,如果一个线程先去写一个变量,另外一个线程再去读,那么写入操作一定在读操作之前。

第4条规则,就是happens-before的传递性。

后面几条就不再一一赘述了。

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值