【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偏向锁

第⼀个尝试加锁的线程, 优先进⼊偏向锁状态.
偏向锁不是真的 "加锁", 只是给对象头中做⼀个 "偏向锁的标记", 记录这个锁属于哪个线程.
如果后续没有其他线程来竞争该锁, 那么就不⽤进⾏其他同步操作了(避免了加锁解锁的开销)
如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别当前
申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进⼊⼀般的轻量级锁状态.
偏向锁本质上相当于 "延迟加锁" . 能不加锁就不加锁, 尽量来避免不必要的加锁开销.
但是该做的标记还是得做的, 否则⽆法区分何时需要真正加锁.