Volatile,Synchronized,Lock

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/GD_Hacker/article/details/80154382

本文主要记载Volatile,Synchronize,Lock特性与适用场景


Volatile

Volatile是一种相比Synchronized更轻量级的同步机制,它能够保证并发处理的可见性,但它并不能够保证原子性,这意味着Volatile并不是线程安全的。

可为可见性?如果某个线程改变了声明为Volatile的变量的值,那么所有其他线程中的值都应该更新,也就是所有线程对该Volatile变量是保持可见的。为了理解这句话,需要牵扯到JMM(Java内存模型)关于变量的存储读取操作,注意这里所说的变量是对应于堆中对象实例的数据,而并非指局部变量和方法参数,因为这些都是线程私有的,不会共享,也就不会存在线程安全问题。学过操作系统的都应该清楚:CPU和内存的运行速度差别很大,如果CPU每次对于一次数据处理,都需要等待数据从内存中读取,那么性能非常低下,所以,在CPU和内存之间加入了缓冲区,用于解决CPU和内存速度不一致的问题。JMM和这个结构类似,对于每一个线程,都有一块线程私有的“缓冲区”,称之为工作内存。见下图(图片来源):
这里写图片描述

这里的高速缓存就是我们所说的工作内存。解释一下JMM中的内存交互操作:
Lock:作用于主内存,用于锁定某一个变量为某一个线程所占有。
Read:作用于主内存,将主内存中的变量读取到工作内存中,为load操作铺垫。
Load:作用于工作内存,将read操作中的数据加载到工作内存的变量副本中。
Use:作用于工作内存,将变量副本交给处理机执行。
Assign:作用于工作内存,为工作内存中的变量副本赋值。
Store:作用于工作内存,将变量副本传送到主内存中,为write操作铺垫。
Write:作用于主内存,将Store的值写到主内存中。
Unlock:作用于主内存,释放对于该变量的锁。

如果我们不采取锁操作(例如Lock()),对于非Volatile变量来说,多个线程就可能保存有该变量的多个副本值,如果同时执行读写操作,那么读的结果就可能不一致。怎么解决?利用Volatile关键字,Volatile声明的变量,不允许存储到工作内存中,读取操作都直接在主内存中进行,并且一旦执行了写操作,主内存的值就立刻更新,保证了所有线程都能获取该变量的最新值,也就是保证了对该变量的可见性。

其实,这里面也遵循了JMM中的Happens-Before原则:对一个Volatile变量的写,必须先于所有之后对这个变量的读。什么意思?本人一开始也认为,程序的执行顺序和我们编写代码的顺序应该是一致的,其实不然,在多核处理器下,为了提高程序执行速度,编译器和处理器可能会对指令重排序!从硬件架构来说,将多条指令不按照程序规定的顺序,分开发送给各个相应电路单元处理,从而导致指令的执行顺序发生变化。当然,重排序也需按照一定的规则:如果两个操作之间缺乏Happens-Before关系,那么JVM可以对它们任意地重排序。假设A操作对Volatile变量做写操作,B操作对Volatile变量做读操作,那么JVM就不会对AB操作重排序,因为它们之间存在Happens-Before原则。也就是说,Volatile的另外一个作用就是阻止指令重排序,其实现方法就是在编译器生成字节码时,在指令序列中插入内存屏障来禁止特定的重排序。内存屏障一共有4类:

  • LoadLoad Barriers:确保Load1数据的装载先于Load2以及所有后续装载指令。
  • StoreStore Barriers:确保Store1的数据对其他处理器可见(会使缓存行无效,并刷新到内存中)先于Store2及所有后续存储指令的装载。
  • LoadStore Barriers:确保Load1数据装载先于Store2及所有后续存储指令刷新到内存。
  • StoreLoad Barriers:确保Store1数据对其他处理器可见(刷新到内存,并且其他处理器的缓存行无效)先于Load2及所有后续装载指令的装载。该指令会使得该屏障之前的所有内存访问指令完成之后,才能执行该屏障之后的内存访问指令。

那为什么说Volatile不能保证原子性呢?我们看一个例子:

public class Main {
    volatile static int a=0;
    //令a不断自增
    public static void write(){
        for(int i=0;i<50000;i++){
            a++;
        }
    }
    public static void main(String[] args) throws InterruptedException {
        //创建2个线程t1、t2
        Thread t1=new Thread(new Runnable(){
            public void run() {
                write();
            }
        });
        t1.start();
        Thread t2=new Thread(new Runnable(){
            public void run() {
                write();
            }
        });
        t2.start();
        //等待所有线程结束
        while(t1.isAlive() || t2.isAlive()){};
        //打印a的值
        System.out.println(a);
    }
}

打印结果:

83984

哎?不是说Volatile变量保证对所有线程是可见的么,为什么不是100000。原因在于a++并不是一个原子操作,它分三步执行:取值+修改+赋值。前面也说过,当某一个线程对volatile变量值更改后,也就是写入主内存后,其余所有变量才会更新,如果某个线程还未执行最后赋值步骤,其他线程就来读取主内存中的数据,问题就出现了!当然对于像a=1这样的原子操作是没问题的。
《Java并发编程实战》中写道:
当且仅当满足以下所有条件时,采应该使用volatile变量:

  • 对变量的写入操作不依赖变量的的当前值,或者你能确保只有单个线程更新变量的值。
  • 该变量不会与其它状态变量一起纳入不变性条件中。
  • 在访问变量时不需要加锁。

Synchronized

Synchronized粒度比Volatile要大,因为Synchronized是方法级别的锁,主要用于修饰实例方法,静态方法,同步代码块。其中修饰实例方法锁定的是当前对象,修饰静态方法锁定的是当前类,修饰同步代码块锁定的是某个对象。下面我们分为修饰方法和修饰同步代码块来介绍Synchronized基本原理:

修饰同步代码块

首先需要了解的是每个在堆中的对象都包含了一个称为对象头部分,这一块主要用于存储对象的HashCode、分代年龄、锁标志位等。其中重量锁,也就是我们所说的Synchronized,存放着一个指向monitor的指针变量。每当一个线程获取到该对象的monitor,它就会处于锁定状态。monitor是由C++实现的,封装为ObjectMonitor对象,对象中存有几个关键属性:

  • _count:计数器,0指示当前对象没有被线程占用,≥1指示锁已占用,数值可以大于1是因为该锁为重入锁。
  • _owner:指向当前占有monitor的线程。
  • _WaitSet:处于等待的线程(也就是java中调用wait()方法)就会封装为C++实现的ObjectWaiter对象,存放在该队列中。
  • _EntryList:如果有多个对象竞争一把锁,而没有拿到锁的线程就会进入锁池。

思路很简单,当一个线程A发现monitor中count为0,取得锁,并置count为1,此时其它线程只能进入_EntryList等待锁释放。如果线程A调用wait()方法,那么线程A释放锁,将count置为0(不一定是1->0,因为线程A可能重入该锁多次,count值累加1),进入等待池,等待被notify唤醒,唤醒后需要进入锁池与其它线程竞争。由javap反编译可以看到,为了实现对同步代码块的锁控制,在同步代码块前后会加入monitorenter和monitorexit指令,用于控制锁定和释放。

修饰方法体

与修饰同步代码块相比,修饰方法体并不是由指令控制锁定,而是在方法体对应的字节码文件的位置插入ACC_SYNCHRONIZED访问标志来告诉JVM该方法需要同步控制。执行该方法前,线程需要先获取monitor,然后在方法完成后,或者方法抛出异常是释放monitor。

Synchronized属于重量锁,原因是每次进行线程的切换,操作系统都需要在核心态和用户态之间切换,耗费大量资源,为此,JDK1.6也对此进行了优化,加入了几种状态锁:偏向锁,轻量锁,重量锁。关于JVM如何对Synchronized优化,可以看看->深入理解Java并发之synchronized实现原理

Lock

Lock定义了锁的接口规范,有三个实现类ReentrantLock, ReentrantReadWriteLock.ReadLock, ReentrantReadWriteLock.WriteLock,重点为ReentrantLock。

ReentrantLock相比较于Synchronized更加灵活,同时因为其是在代码中实现,避免了像Synchronized需要切换用户态和核心态消耗较多的资源。不过在JDK1.6对Synchronized优化后,性能已经与ReentrantLock差不多,具体使用根据实际情况。

为什么说ReentrantLock更加灵活呢?因为其不仅可以实现公平锁和非公平锁,也可以规定线程等待锁时间,在锁池中的线程是否可以中断。而Synchronized默认为非公平锁并且处于锁池中的线程无法中断。并且,ReentrantLock提供了Condition,对于线程的等待和唤醒更加灵活。具体分析参考这里

展开阅读全文

没有更多推荐了,返回首页