1. 乐观锁 vs 悲观锁

悲观锁：
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。

乐观锁：
假设数据一般情况下不会产生并发冲突，在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则返回用户错误的信息，让用户决定如何去做。

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

假设我们需要多线程修改 “用户账户余额”.
设当前余额为 100. 引入一个版本号 version, 初始值为 1. 并且我们规定 “提交版本必须大于记录当前版本才能执行更新余额”

1. 线程 A 此时准备将其读出（ version=1, balance=100 ），线程 B 也读入此信息（ version=1, balance=100 ）.
2. 线程 A 操作的过程中并从其帐户余额中扣除 50（ 100-50 ），线程 B 从其帐户余额中扣除 20 （ 100-20 ）；
3. 线程 A 完成修改工作，将数据版本号加1（ version=2 ），连同帐户扣除后余额（ balance=50 ），写回到内存中;
4. 线程 B 完成了操作，也将版本号加1（ version=2 ）试图向内存中提交数据（ balance=80 ），但此时比对版本发现，操作员 B 提交的数据版本号为 2 ，数据库记录的当前版本也为 2 ，不满足 “提交版本必须大于记录当前版本才能执行更新“ 的乐观锁策略。就认为这次操作失败.

悲观锁预期锁冲突概率很高，做的工作更多，付出成本更多，更低效
乐观锁预期锁冲突概率很低，做的工作更少，付出成本更少，更高效

Synchronized 初始使用乐观锁策略. 当发现锁竞争比较频繁的时候, 就会自动切换成悲观锁策略.

2. 读写锁 vs 普通互斥锁

读写锁就是把读操作和写操作区分对待. Java 标准库提供了 ReentrantReadWriteLock 类, 实现了读写锁.

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

其中：

• 读加锁和读加锁之间, 不互斥.
• 写加锁和写加锁之间, 互斥.
• 读加锁和写加锁之间, 互斥.

读写锁特别适合于 “频繁读, 不频繁写” 的场景中
Synchronized 不是读写锁， 就是普通的互斥锁

3. 重量级锁 vs 轻量级锁

锁的核心特性 “原子性”, 这样的机制追根溯源是 CPU 这样的硬件设备提供的.

• CPU 提供了 “原子操作指令”.
• 操作系统基于 CPU 的原子指令, 实现了 mutex 互斥锁.
• JVM 基于操作系统提供的互斥锁, 实现了 synchronized 和 ReentrantLock 等关键字和类.

注意, synchronized 并不仅仅是对 mutex 进行封装, 在 synchronized 内部还做了很多其他的工作

重量级锁: 加锁机制重度依赖了 OS 提供了 mutex

• 大量的内核态用户态切换
• 很容易引发线程的调度

轻量级锁: 加锁机制尽可能不使用 mutex, 而是尽量在用户态代码完成. 实在搞不定了, 再使用 mutex.

• 少量的内核态用户态切换.
• 不太容易引发线程调度.

重量级锁加锁解锁开销比较大，效率较低，多数情况下悲观锁是重量级锁
轻量级锁加锁解锁开销比较小，效率较高，多数情况下乐观锁是轻量级锁

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

4. 自旋锁（Spin Lock）vs 挂起等待锁

挂起等待锁（典型的重量级锁）：线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度.

但实际上, 大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。没必要就放弃 CPU. 这个时候就可以使用自旋锁（典型的轻量级锁）来处理这样的问题.

自旋锁伪代码:

while (抢锁(lock) == 失败) {}

如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来.
一旦锁被其他线程释放, 就能第一时间获取到锁.

自旋锁是一种典型的 轻量级锁 的实现方式.

• 优点: 没有放弃 CPU, 不涉及线程阻塞和调度, 一旦锁被释放, 就能第一时间获取到锁.
• 缺点: 如果锁被其他线程持有的时间比较久, 那么就会持续的消耗 CPU 资源. (而挂起等待的时候是不消耗 CPU 的).

synchronized 中的轻量级锁策略大概率就是通过自旋锁的方式实现的.

5. 公平锁 vs 非公平锁

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

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

注意:

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

synchronized 是非公平锁

6. 可重入锁 vs 不可重入锁

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

举个栗子：

        Object locker = new Object();synchronized (locker) {System.out.println("第一次加锁");synchronized (locker) {System.out.println("第二次加锁");}}

按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第二个锁. 但是释放第一个锁也是由该线程来完成, 这个线程也就无法进行解锁操作. 这时候就会 死锁.

如果上述这种情况能造成死锁就是不可重入锁， 否则就是可重入锁。

synchronized 是可重入锁

7. Synchronized

1. 既是乐观锁，又是悲观锁， 当锁冲突比较激烈时，从乐观锁变为悲观锁
2. 既是轻量级锁，又是重量级锁，
3. Synchronized的轻量级锁基于自旋锁实现， 重量级锁基于挂起等待锁实现
4. 不是读写锁， 只是普通的互斥锁
5. 是可重入锁
6. 是非公平锁

8. 相关面试题

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

• 悲观锁认为多个线程访问同一个共享变量冲突的概率较大, 会在每次访问共享变量之前都去真正加锁.

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

• 悲观锁的实现就是先加锁(比如借助操作系统提供的 mutex), 获取到锁再操作数据. 获取不到锁就等待.

• 乐观锁的实现可以引入一个版本号. 借助版本号识别出当前的数据访问是否冲突.

2. 介绍下读写锁?

• 读写锁就是把读操作和写操作分别进行加锁.
• 读锁和读锁之间不互斥.
• 写锁和写锁之间互斥.
• 写锁和读锁之间互斥.

读写锁最主要用在 “频繁读, 不频繁写” 的场景中.

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

• 如果获取锁失败, 立即再尝试获取锁, 无限循环, 直到获取到锁为止. 第一次获取锁失败, 第二次的尝试会在极短的时间内到来. 一旦锁被其他线程释放, 就能第一时间获取到锁.

相比于挂起等待锁,

• 优点: 没有放弃 CPU 资源, 一旦锁被释放就能第一时间获取到锁, 更高效. 在锁持有时间比较短的场景下非常有用.
• 缺点: 如果锁的持有时间较长, 就会浪费 CPU 资源.

4. synchronized 是可重入锁么？

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

好啦！ 以上就是对 常见的锁策略 的讲解，希望能帮到你 ！
评论区欢迎指正 !