【Java】常见锁策略 && CAS机制 &&锁优化策略-慈云数据

在这里插入图片描述

前言

在本文会详细介绍各种锁策略、CAS机制以及锁优化策略

不仅仅局限于Java，任何和锁相关的话题，都可能会涉及到下面的内容。

这些特性主要是给锁的实现者来参考的.

普通的程序猿也需要了解一些, 对于合理的使用锁也是有很大帮助的

文章目录

前言
✍一、常见的锁策略
- 1.1乐观锁悲观锁
- 1.2重量级锁轻量级锁
- 1.3自旋锁挂起等待锁
- 1.4公平锁非公平锁
- 1.5可重入锁不可重入锁
- 1.6读写锁
- ✍二、CAS机制
- - 2.1概念
  - 2.2如何实现？
  - 2.3有何应用？
  - - ①实现原子类
    - ②实现自旋锁
    - 2.4锁的ABA问题
    - ✍三、锁优化策略
    - - 3.1偏向锁
      - 3.2轻量级锁
      - 3.3自旋锁
      - 3.4其他锁优化
      - ①锁消除
        ②锁粗化
        ✍一、常见的锁策略
        
        1.1乐观锁悲观锁
        
        乐观锁：预测到程序中遇到冲突的可能性较小，从而消耗的资源（时间资源，内存资源）都比较少。
        悲观锁：预测到程序中遇到冲突的可能性比较大，从而消耗的资源（时间资源，内存资源）比较多。
        
        可以将悲观锁抽象理解为拥有被害妄想症
        
        我们来画图再次具象的理解一下：
        
        我们站在乐观锁的角度，认为程序中读数据的操作远远多于写数据的操作，所以在一般情况下，不会对程序进行加锁。
        
        我们站在悲观锁的角度，认为程序中写操作远远多于读数据的操作，所以每次进行操作时就需要加锁。
        
        那么对于我们熟知的synchronized锁来说，它是什么锁呢？
        synchronized既是乐观锁，也是悲观锁，拥有自适应机制
        初始为乐观锁，当检测到程序中锁的竞争较大时，就会切换悲观锁。
        
        1.2重量级锁轻量级锁
        
        我们先来理解一下资源在计算机中时如何操作的
        重量级锁：
        
        重量级锁过度依赖了操作系统提供的mutex（互斥锁），这种锁同步方式的消耗非常大，主要包括系统调度引起的用户态和内核态的切换，线程阻塞造成的线程调度问题。
        
        轻量级锁：
        
        轻量级锁的加锁机制尽可能的不使用mutex，从而减少了内核态和用户态之间的切换。也减少了线程的调度问题。
        
        那么对于我们熟知的synchronized锁来说，它是什么锁呢？
        synchronized刚开始是一个轻量级锁，它会检测发生冲突的情况，如果冲突比较严重，就会变成重量级锁。
        
        1.3自旋锁挂起等待锁
        
        自旋锁（Spin Lock）
        当程序中出现锁竞争时，锁对象要不断的检测锁是否归还，一旦锁被归还，那么就能第一时间拿到锁。但会消耗更多CPU资源，更多的时候是在判断锁是否归还。
        
        我们写出一段关于自旋锁的伪代码来更深入的理解
        
        while（抢锁 == 失败） {}
        
        如果抢锁失败的话，就会一直重复的进行这一步操作，直到抢到锁为止。一次次抢锁之间的间隔时间非常短。
        
        一旦锁被其他线程释放，就能第一时间获取到锁。
        
        自旋锁的优缺点
        
        优点：一旦锁被释放，能第一时间拿到锁
        缺点：会造成资源的浪费，CPU一昧的在空等。
        挂起等待锁
        当锁竞争时，锁对象会等待一时间，不着急拿到锁，过一段时间再进行抢锁，消耗的CPU资源比较少。
        
        挂起等待锁的优缺点
        
        优点：减少了资源的消耗
        缺点：不知道什么时候能拿到锁。
        自旋锁和挂起等待锁的区别
        
        自旋锁消耗的资源要比挂起等待锁多，但自旋锁的效率高于挂起等待锁
        挂起等待锁会放弃CPU资源，自选锁不会放弃，会一直到锁释放为止。
        自旋锁相较于挂起等待锁能更及时的获取到刚释放的锁
        那么对于我们熟知的synchronized锁来说，它是什么锁呢？
        synchronized既是自旋锁，也是挂起等待锁。
        synchronized锁的轻量级锁是基于自旋锁实现的，基于CAS机制
        重量级锁部分基于挂起等待锁实现，通过调用内核api实现。
        
        1.4公平锁非公平锁
        
        这种锁策略代表着当多个锁竞争时，竞争的规则是什么？
        公平锁：按照先来后到的规则来竞争锁。
        非公平锁：竞争锁时每个对象的机会时均等的。
        
        这种规则是不是不符合我们生活所理解的所认为的公平
        生活就是这样，制定规则的人说什么是公平，那什么就是公平。
        
        那么对于我们熟知的synchronized锁来说，它是什么锁呢？
        synchronized是非公平锁，也就是机会均等的竞争锁。
        
        1.5可重入锁不可重入锁
        
        这种锁策略是用来规定是否允许同一个线程获取同意一把锁
        例如递归操作中有锁操作，那么递归过程中这个锁会阻塞自己吗？
        如果不会，那就是可重入锁
        
        在可重⼊锁的内部, 包含了线程持有者和计数器两个信息.
        
        如果某个线程加锁的时候, 发现锁已经被⼈占用, 但是恰好占⽤的正是自己, 那么仍然可以继续获取到锁, 并让计数器自增.
        解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)
        管理是有成本的，可重入锁看起来很理想，但需要考虑是否有必要引入该成本。
        
        那么对于我们熟知的synchronized锁来说，它是什么锁呢？
        synchronized是可重入锁
        mutex锁是不可重入锁
        
        1.6读写锁
        
        多线程之间，数据的读取不会产生线程安全问题，但数据的写入方相互之间以及和读者之间都需要进行互斥。如果两种场景之间都用同一个锁，就会产生极大的性能消耗。
        
        一个线程对数据的访问，主要哟两种操作：读操作和写操作
        
        两个线程都只读一个数据，此时并没有线程安全问题，直接并发的读即可
        两个线程都要写一个数据，引发线程安全问题
        一个线程读，一个线程写，也会引发线程安全问题
        线程安全问题转移我上一篇文章链接: 线程安全问题
        读写锁
        
        ReentrantReadWriteLock.ReadLock //读锁 ReentrantReadWriteLock.WriteLock //写锁
        
        读锁和写锁都提供了lock/unlock方法进行加锁解锁
        
        读加锁和读加锁之间，不互斥
        写加锁和写加锁之间，互斥
        读加锁和写加锁之间，互斥
        读写锁主要适用于“频繁读，不频繁写”的场景中
        
        那么对于我们熟知的synchronized锁来说，它是什么锁呢？
        synchronized不是读写锁
        
        ✍二、CAS机制
        
        2.1概念
        
        CAS：全程Compare and swap，字面意思是“比较并交换”
        CAS操作就是将赋值这一操作进行原子化了。
        
        CAS涉及的操作
        
        假设内存中的原数据V，旧的预期值A，新的预期值B
        
        比较A与V是否相等（比较）
        
        如果比较相等，将B写入V （交换）
        
        返回操作是否成功
        
        CAS可以视为是一种乐观锁（可以理解成CAS是乐观锁的一种实现方式）当多个线程对某个资源进行CAS操作，只能有一个线程能操作成功。但是并不会阻塞其他线程，其他线程只会收到操作失败的信号。
        
        2.2如何实现？
        
        CAS是如何实现的？
        针对不同的操作系统，JVM用到了不同的CAS实现原理，简单来讲：
        
        Java的CAS利用的是unsafe这个类提供的CAS操作；
        unsafe的CAS依赖的是jvm针对不同的操作系统实现的Atomic::cmpxchg；
        Atomic::cmpxchg的实现使用了汇编的CAS操作，并使用cpu硬件提供的lock机制保证其原子性。
        2.3有何应用？
        
        CAS有哪些应用？
        
        ①实现原子类
        
        AtomicInteger atomicInteger = new AtomicInteger(0); //相当于 i++; atomicInteger.getAndIncrement();
        
        假设两个线程同时调用gerAndIncrement
        
        1.两个线程都读取value的值到oldValue中，（oldValue是一个局部变量，在栈上，每个线程有自己的栈）
        
        2.线程1先执行CAS操作，由于oldValue和value的值相同，直接及逆行value赋值
        
        注意 · CAS是直接读写内存的，而不是操作寄存器 · CAS的读内存，比较，写内存操作是一条硬件指令，是原子的
        
        3.线程2执行CAS，执行第一次时，发现oldValue和value的值不相等，不能进行赋值。因此需要进入循环。
        在循环里重新读取value的值赋给oldValue
        4.线程2接下第二次执行CAS（此时因为第一次没有成功，所以还在while循环中），此时oldValue和value相同，于是直接执行赋值操作。
        5.线程1和线程2返回各自的oldValue的值即可。
        
        形如上述代码就可用实现一个原子类，不需要使用重量级锁，就可以高效的完成自增操作。
        
        ②实现自旋锁
        
        自旋锁伪代码
        
        class SpinLock{ private Thread owner = null; private void lock(){ //通过CAS看当前锁是否被某个线程私有 //如果这个锁已经被别的线程私有，那么就自旋等待 //如果这个锁没有被其他线程私有，那么就把owner设为当前尝试加锁的线程。 while (!CAS(this.owner,null,Thread.currentThread())){ } } public void unlock(){ this.owner = null; } }
        
        2.4锁的ABA问题
        
        ABA问题：
        假设存在两个线程t1和t2，有一个共享变量num，初始值为A
        接下来，线程t1想使用CAS把num值改成Z，那么就需要
        
        先读取num的值，记录到oldNum变量中
        是同CAS判定当前num的值是否为A，如果为A，就修改为Z。
        线程t1的CAS期望时num不变就修改为，但num的值已经被t2给改了，只不过又改成A了，这个时候t1究竟是否要更新num的值为Z呢？
        
        到这一步，t1线程无法区分当前这个变量始终是A，还是经历了一个变化过程。
        
        引起的BUG
        在大部分情况下，是没有问题的，但总是存在一些特殊情况
        
        小帅和小美生育有一子，孩子两岁了，需要去打疫苗，医院给小帅和小美发去了短信，要求他们这周末孩子去医院打疫苗，并在社区医院的表格报备；
        我们期望一个人带孩子去打疫苗并在社区医院表格中报备了，另一个人发现已经报备了，不需要再打疫苗了。
        如果使用CAS的方式来完成这个打疫苗过程就可能出现问题。
        
        正常的过程
        
        小帅看见社区医院的表格没有报备，小帅带孩子去打疫苗。小美看见社区医院的表格没有报备，小美带孩子去打疫苗
        小帅带孩子打了疫苗，孩子被小帅带走了，小美在家等待。
        小帅带孩子回来了，并在社区医院表格中报备，小美通过查看表格知道了孩子已经打了疫苗，就不带孩子去医院了。
        异常BUG
        
        小帅看见社区医院的表格没有报备，小帅带孩子去打疫苗。小美看见社区医院的表格没有报备，小美带孩子去打疫苗
        小帅带孩子打了疫苗，孩子被小帅带走了，小美在家等待。
        小帅带孩子打完了疫苗，公司有事，把孩子送回家马上回公司了，并没有在社区医院表格中报备。此时小美拿到孩子，看见表格中没有报备，以为小帅带孩子出去玩了。小美就带孩子去了医院
        小美到医院给医生说，孩子要打疫苗，孩子又被打了一针疫苗
        这时孩子就被打了两次疫苗！！！都是ABA问题搞的鬼。孩子过两天就死了！！！孩子才两岁，也不会说话！！！吃了没文化的亏！！！所以奉劝大家一定要好好学习哈哈
        
        既然问题这么严重，就给出解决方案来解决这个问题
        
        解决方案
        给要修改的值，引入版本号，在CAS比较数据当前值和旧值的同时，也要比较版本号是否符合预期。
        
        CAS操作在读取旧值的同时，也要读取版本号。
        真正修改的时候，
        – 如果当前版本号和读到的版本号相同，则修改数据，并把版本号+1.
        –如果当前版本号高于读到的版本号，就操作失败（认为数据已经被修改过了）。
        对比理解上面打疫苗的例子
        
        版本号就相当于医院的疫苗接种单打了疫苗，医院就会在疫苗接种单上盖章。我们搭配一个版本号，初始为1
        
        小帅看见社区医院的表格没有报备，版本号为1，小帅带孩子去打疫苗。小美看见社区医院的表格没有报备，版本号为1，小美带孩子去打疫苗
        小帅带孩子打了疫苗，孩子被小帅带走了，打了疫苗，版本号为2，小美在家等待。
        小帅带孩子打完了疫苗，公司有事，把孩子送回家马上回公司了，并没有在社区医院表格中报备，但版本号为2。
        此时小美拿到孩子，看见表格中没有报备，以为小帅带孩子出去玩了。小美就准备带孩子去医院，但是发现此时版本号为2，和之前读到的版本号1不相同，版本小于当前版本，认为操作失败。
        ✍三、锁优化策略
        
        JVM将synchronized锁分为无锁、偏向锁、轻量级锁、重量级锁。
        会根据情况，进行一次升级。
        
        3.1偏向锁
        
        第⼀个尝试加锁的线程, 优先进⼊偏向锁状态. 偏向锁不是真的 "加锁", 只是给对象头中做⼀个 "偏向锁的标记", 记录这个锁属于哪个线程. 如果后续没有其他线程来竞争该锁, 那么就不⽤进⾏其他同步操作了(避免了加锁解锁的开销) 如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进⼊⼀般的轻量级锁状态. 偏向锁本质上相当于 "延迟加锁" . 能不加锁就不加锁, 尽量来避免不必要的加锁开销. 但是该做的标记还是得做的, 否则⽆法区分何时需要真正加锁.
        
        3.2轻量级锁
        
        随着其他线程进⼊竞争, 偏向锁状态被消除, 进⼊轻量级锁状态(⾃适应的⾃旋锁).
        此处的轻量级锁就是通过 CAS 来实现.
        
        通过 CAS 检查并更新⼀块内存 (⽐如 null => 该线程引⽤)
        如果更新成功, 则认为加锁成功
        如果更新失败, 则认为锁被占⽤, 继续⾃旋式的等待(并不放弃 CPU).
        ⾃旋操作是⼀直让 CPU 空转, ⽐较浪费 CPU 资源.
        因此此处的⾃旋不会⼀直持续进⾏, ⽽是达到⼀定的时间/重试次数, 就不再⾃旋了.
        也就是所谓的 “⾃适应”
        
        3.3自旋锁
        
        如果竞争进⼀步激烈, ⾃旋不能快速获取到锁状态, 就会膨胀为重量级锁
        此处的重量级锁就是指⽤到内核提供的 mutex .
        
        执⾏加锁操作, 先进⼊内核态.
        在内核态判定当前锁是否已经被占⽤
        如果该锁没有占⽤, 则加锁成功, 并切换回⽤⼾态.
        如果该锁被占⽤, 则加锁失败. 此时线程进⼊锁的等待队列, 挂起. 等待被操作系统唤醒.
        经历了⼀系列的沧海桑⽥, 这个锁被其他线程释放了, 操作系统也想起了这个挂起的线程, 于是唤醒
        这个线程, 尝试重新获取锁.
        3.4其他锁优化
        
        ①锁消除
        
        编译器+JVM 判断锁是否可消除. 如果可以, 就直接消除.
        
        ②锁粗化
        
        ⼀段逻辑中如果出现多次加锁解锁, 编译器 + JVM 会⾃动进⾏锁的粗化
        
        锁的颗粒：锁的粒度: 粗和细
        实际开发过程中, 使⽤细粒度锁, 是期望释放锁的时候其他线程能使⽤锁.
        但是实际上可能并没有其他线程来抢占这个锁. 这种情况 JVM 就会⾃动把锁粗化, 避免频繁申请释放
        锁.
        
        举个例子来理解锁粗化
        
        小明妈妈让小明去超市买东西
        
        第一种方式
        
        打电话，让小明买酱油，挂电话
        打电话，让小明买白醋，挂电话
        打电话，让小明买抹布，挂电话
        第二种方式
        
        打电话，让小明买酱油，白醋，抹布，挂电话
        显然第二种方式更高效
        
        以上就是本文所有内容，如果对你有帮助的话，点赞收藏支持一下吧！💞💞💞