前言
在本文会详细介绍各种锁策略、CAS机制以及锁优化策略
不仅仅局限于Java，任何和锁相关的话题，都可能会涉及到下面的内容。
这些特性主要是给锁的实现者来参考的.
普通的程序猿也需要了解一些, 对于合理的使用锁也是有很大帮助的
✍一、常见的锁策略
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 就会⾃动把锁粗化, 避免频繁申请释放
锁.
举个例子来理解锁粗化
小明妈妈让小明去超市买东西
第一种方式
- 打电话，让小明买酱油，挂电话
- 打电话，让小明买白醋，挂电话
- 打电话，让小明买抹布，挂电话
第二种方式
- 打电话，让小明买酱油，白醋，抹布，挂电话
显然第二种方式更高效文章来源：https://www.toymoban.com/news/detail-855440.html
以上就是本文所有内容，如果对你有帮助的话，点赞收藏支持一下吧！💞💞💞文章来源地址https://www.toymoban.com/news/detail-855440.html
到了这里，关于【Java】常见锁策略 && CAS机制 &&锁优化策略的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
