【JavaEE】常见的锁策略都有哪些？

墨蓝 2024-03-23 12:31 13阅读 0赞

## ![65ccf3f13fbd4d1eb832d8b1f42bdd5c.gif][] ##

>  *  **博主简介：想进大厂的打工人**
>  *  **博主主页：**[@xyk:][xyk]
>  *  **所属专栏: [JavaEE初阶][JavaEE]**

在Java多线程中，常见的锁策略都有哪些？这些锁策略应该怎么理解？ （乐观锁vs悲观锁，轻量级锁vs重量级锁，自旋锁vs挂起等待锁，互斥锁vs读写锁，可重入锁vs不可重入锁，公平锁vs非公平锁）

常见的锁策略，注意: 接下来讲解的锁策略不仅仅是局限于 Java . 任何和 "锁" 相关的话题, 都可能会涉及到以下内容. 这些特性主要是给锁的实现者来参考的，普通的程序猿也需要了解一些, 对于合理的使用锁也是有很大帮助的.

--------------------

**目录**

一、乐观锁vs悲观锁

1.1 乐观锁的功能

二、轻量级锁vs重量级锁

三、自旋锁vs挂起等待锁

四、互斥锁vs读写锁

五、可重入锁vs不可重入锁

六、公平锁vs非公平锁

七、相关面试题

7.1 你是怎么理解乐观锁和悲观锁的，具体怎么实现呢？

7.2 介绍下读写锁?

7.3 什么是自旋锁，为什么要使用自旋锁策略呢，缺点是什么？

7.4 synchronized 是可重入锁么？

--------------------

**一、乐观锁vs悲观锁**

锁的实现者，预测接下来锁冲突的概率是大，还是不大，根据这个冲突的概率，来决定接下来该咋做~~

锁冲突就是锁竞争，俩个线程针对一个对象加锁，产生阻塞等待了~~

乐观锁vs悲观锁：

乐观锁：预测接下来冲突概率不大，做的工作会更少一些，效率更高一些（并不绝对）

悲观锁：预测接下来冲突概率比较大，做个工作要多一些，效率会低一些（并不绝对）

举个例子：

比如去年疫情放开了，有的人，乐观，觉得放开了也没啥事，也没有做啥准备，有的人，悲观，放开了影响会很大，于是就买了很多东西：药，吃的，酒精，手套等等....

#### 1.1 乐观锁的功能 ####

乐观锁的一个重要功能就是要检测出数据是否发生访问冲突. 我们可以引入一个 "版本号" 来解决

> 假设我们需要多线程修改 "用户账户余额"  
> 设当前余额为 100. 引入一个版本号 version, 初始值为 1. 并且我们规定 "提交版本必须大于记录当前版本才能执行更新余额"  
> 1) 线程 A 此时准备将其读出（ version=1, balance=100 ），线程 B 也读入此信息（ version=1,balance=100 ）  
> ![be11a840a8894a328a33848d9ee2e910.png][]

> 2) 线程 A 操作的过程中并从其帐户余额中扣除 50（ 100-50 ），线程 B 从其帐户余额中扣除 20（ 100-20 ）；  
> ![86afc47b2633452793e782c94933b815.png][]

> 3) 线程 A 完成修改工作，将数据版本号加1（ version=2 ），连同帐户扣除后余额（ balance=50），写回到内存中;  
> ![92e5048131824736b8c422067946e266.png][]

> 4) 线程 B 完成了操作，也将版本号加1（ version=2 ）试图向内存中提交数据（ balance=80  
> ），但此时比对版本发现，操作员 B 提交的数据版本号为 2 ，数据库记录的当前版本也为 2 ，不满足 “提交版本必须大于记录当前版本才能执行更新“ 的乐观锁策略。就认为这次操作失败.  
> ![5f1b1c3377e94086a8ce11c5d94755de.png][]

## **二、轻量级锁vs重量级锁** ##

### `` ###

轻量级锁：加锁解锁，过程更快更高效

重量级锁：加锁解锁，过程更慢，更低效

和乐观锁和悲观锁，虽然不是一回事，但是确实有一定的重合~~一个乐观锁很可能也是一个轻量级锁，一个悲观锁也很可能是一个重量级锁（不绝对）

synchronized 开始是一个轻量级锁. 如果锁冲突比较严重, 就会变成重量级锁.

## 三、自旋锁vs挂起等待锁 ##

自旋锁：是轻量级锁的一种经典实现

> 伪码：
> 
>     while (抢锁(lock) == 失败) {}

挂起等待锁：是重量级锁的一种经典实现

自旋锁会一直去尝试获取锁，一旦锁被释放，就第一时间拿到锁，速度会更快，无时无刻都要去尝试获取，干不了别的（忙等，消耗cpu资源）通常是纯用户态的，不需要经过内核态（时间相对更短）

挂起等待锁不会去一直尝试获取锁，如果锁被释放，不能第一时间拿到锁，可能需要过很久才能拿到锁，这个时间是空闲出来的，可以趁机做别的（不消耗cpu资源）（通过内核的机制，来实现挂起等待，时间更长）

> 想象一下, 去追求一个女神. 当男生向女神表白后, 女神说: 你是个好人, 但是我有男朋友了~~  
> 挂起等待锁: 陷入沉沦不能自拔.... 过了很久很久之后, 突然女神发来消息, "咱俩要不试试?" (注意,这个很长的时间间隔里, 女神可能已经换了好几个男票了).  
> 自旋锁: 死皮赖脸坚韧不拔. 仍然每天持续的和女神说早安晚安. 一旦女神和上一任分手, 那么就能立刻抓住机会上位.

针对上述三组策略，synchronized属于哪把锁？

synchronized即是乐观锁，也是悲观锁，即使轻量级锁，也是重量级锁，轻量级锁部分基于自旋锁实现，重量级锁部分基于挂起等待锁实现~~

## 四、互斥锁vs读写锁 ##

> 多线程之间，数据的读取方之间不会产生线程安全问题，但数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁，就会产生极大的性能损耗。所以读写锁因此而产生。

读写锁：能够把 读 和 写 两种加锁区分开，Java 标准库提供了 ReentrantReadWriteLock 类, 实现了读写锁.

> ReentrantReadWriteLock.ReadLock 类表示一个读锁. 这个对象提供了 lock / unlock 方法进行加锁解锁.  
> ReentrantReadWriteLock.WriteLock 类表示一个写锁. 这个对象也提供了 lock / unlock 方法进行加锁解锁.

1.给读加锁

2.给写加锁

3.解锁

> 如果多个线程读同一个变量，不会涉及到线程安全问题！！！

读写锁中，约定：

1.读锁和读锁之间，不会锁竞争，不会产生阻塞等待（不会影响程序的速度，代码还是跑很快）

2.写锁和写锁之间，有锁竞争

3.读写和写锁之间，也有锁竞争

读写锁更适合于，一写多读的情况！！！

> 2，3点会减慢速度，但是保证准确性~~

互斥锁：

synchronized 不是读写锁，是互斥锁，加锁就只是单纯的加锁，没有更细化的区分了~~

像synchronized只有俩个操作：

1.进入代码块，加锁

2.出了代码块，解锁

## 五、可重入锁vs不可重入锁 ##

可重入锁的字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。

如果一个锁，在一个线程中，连续对该锁加锁俩次，不死锁，就叫做可重入锁，如果死锁了，就叫不可能重入锁~~

> ![6f27f5bfa5cc452ca9300ed2930258ff.png][]
> 
> 按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第二个锁. 但是释放第一个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无法进行解锁操作. 这时候就会 死锁

> Java里只要以Reentrant开头命名的锁都是可重入锁，而且JDK提供的所有现成的Lock实现类，包括synchronized关键字锁都是可重入的

synchronized 是可重入锁

## 六、公平锁vs非公平锁 ##

![5b12840054294e5e8740e8e9222cf5ec.png][]

公平锁: 遵守 "先来后到".B 比 C 先来的. 当 A 释放锁的之后, B 就能先于 C 获取到锁.

> ![f4b0f166006949e9b0c4943474d6820d.png][]

非公平锁: 不遵守 "先来后到". B 和 C 都有可能获取到锁.

>   
> ![043bb86fc7334df08cc7485c209e6390.png][]

> 注意:
> 
>  *  操作系统内部的线程调度就可以视为是随机的. 如果不做任何额外的限制, 锁就是非公平锁. 如果要想实现公平锁, 就需要依赖额外的数据结构, 来记录线程们的先后顺序.
>  *  公平锁和非公平锁没有好坏之分, 关键还是看适用场景.

synchronized是非公平锁

## 七、相关面试题 ##

### 7.1 你是怎么理解乐观锁和悲观锁的，具体怎么实现呢？ ###

> 悲观锁认为多个线程访问同一个共享变量冲突的概率较大, 会在每次访问共享变量之前都去真正加锁.  
> 乐观锁认为多个线程访问同一个共享变量冲突的概率不大. 并不会真的加锁, 而是直接尝试访问数据. 在访问的同时识别当前的数据是否出现访问冲突

### 7.2 介绍下读写锁? ###

> 读写锁就是把读操作和写操作分别进行加锁.  
> 读锁和读锁之间不互斥.  
> 写锁和写锁之间互斥.  
> 写锁和读锁之间互斥.  
> 读写锁最主要用在 "频繁读, 不频繁写" 的场景中

### 7.3 什么是自旋锁，为什么要使用自旋锁策略呢，缺点是什么？ ###

> 如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来. 一旦锁被其他线程释放, 就能第一时间获取到锁.
> 
> 相比于挂起等待锁，
> 
> 优点: 没有放弃 CPU 资源, 一旦锁被释放就能第一时间获取到锁, 更高效. 在锁持有时间比较短的场景下非常有用.  
> 缺点: 如果锁的持有时间较长, 就会浪费 CPU 资源

### 7.4 synchronized 是可重入锁么？ ###

> 是可重入锁.  
> 可重入锁指的就是连续两次加锁不会导致死锁.  
> 实现的方式是在锁中记录该锁持有的线程身份, 以及一个计数器(记录加锁次数). 如果发现当前加锁的线程就是持有锁的线程, 则直接计数自增

[65ccf3f13fbd4d1eb832d8b1f42bdd5c.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/edbc50697ada418c8be72efa4d06f8ba.png
[xyk]: https://blog.csdn.net/asad21654864?spm=1000.2115.3001.5343
[JavaEE]: https://blog.csdn.net/asad21654864/category_12243955.html?spm=1001.2014.3001.5482
[be11a840a8894a328a33848d9ee2e910.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/a909ad711e4c45c3ab42e53ecd611413.png
[86afc47b2633452793e782c94933b815.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/8c9ef04628d74cd6a3ee7cbfc4cf1abb.png
[92e5048131824736b8c422067946e266.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/83c1f7b921db474f825c422030070942.png
[5f1b1c3377e94086a8ce11c5d94755de.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/6bbc7cb7982f4ff0b883553199441739.png
[6f27f5bfa5cc452ca9300ed2930258ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/95a8f69e73b242798092f5dc1fd6059f.png
[5b12840054294e5e8740e8e9222cf5ec.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/6f151cf17d0543cdb172e80029bc7d2f.png
[f4b0f166006949e9b0c4943474d6820d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/53e21ee3cfd144978624ef801d44c730.png
[043bb86fc7334df08cc7485c209e6390.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/d5bd69645420409a8c5ebca99df186fa.png