✨个人主页：bit me👇
✨当前专栏：Java EE初阶👇
✨每日一语：老当益壮，宁移白首之心；穷且益坚，不坠青云之志。

锁策略：加锁的时候咋加的

---

🏳️一. 乐观锁 vs 悲观锁

• 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
• 乐观锁：假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。

Synchronized 就既是一个悲观锁，也是一个乐观锁，是一种自适应锁。当前锁冲突概率不大，以乐观锁方式运行，往往是纯用户态执行的，一旦发现锁冲突概率大了，以悲观锁的方式运行，往往要进入内核，对当前线程进行挂起等待。

---

🏴二. 普通的互斥锁 vs 读写锁

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

• Synchronized就属于普通的互斥锁，两个加锁操作之间会发生竞争
• 读写锁，把加锁操作细化了，加锁分成了 “加读锁” “加写锁”。

读写锁（readers-writer lock），看英文可以顾名思义，在执行加锁操作时需要额外表明读写意图，复数读者之间并不互斥，而写者则要求与任何人互斥。

一个线程对于数据的访问, 主要存在两种操作: 读数据 和 写数据.

• 两个线程都只是读一个数据, 此时并没有线程安全问题. 直接并发的读取即可.
• 两个线程都要写一个数据, 有线程安全问题.
• 一个线程读另外一个线程写, 也有线程安全问题.

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

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

其中,

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

注意, 只要是涉及到 “互斥”, 就会产生线程的挂起等待. 一旦线程挂起, 再次被唤醒就不知道隔了多久了.
 
因此尽可能减少 “互斥” 的机会, 就是提高效率的重要途径

读写锁特别适合于 “频繁读, 不频繁写” 的场景中

---

🏁三. 重量级锁 vs 轻量级锁

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

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

重量级锁：锁开销比较大，做的工作比较多。

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

主要是依赖了 操作系统 提供的锁，使用这种锁，就容易产生阻塞等待。

轻量级锁：锁开销比较小，做的工作比较少。

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

主要尽量避免使用 操作系统 提供的锁，而是尽量在用户态来完成功能，尽量避免 用户态 和 内核态 的切换，尽量避免挂起等待。

synchronized 是自适应锁，也是一个轻量级锁. 如果锁冲突比较严重, 就会变成重量级锁。

---

🚩四. 自旋锁 vs 挂起等待锁

• 自旋锁：是轻量级锁的具体实现
• 挂起等待锁：是重量级锁的具体实现

自旋锁是轻量级锁，也是乐观锁
挂起等待锁是重量级锁，也是悲观锁

按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度。但实际上, 大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。没必要就放弃 CPU. 这个时候就可以使用自旋锁来处理这样的问题。自旋锁发现锁冲突的时候，不会挂起等待，会迅速再来尝试看这个锁能不能获取到

自旋锁伪代码：

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

自旋锁特点：

1. 一旦锁被释放，就可以第一时间获取到
2. 如果锁一直不释放，就会消耗大量的 CPU

挂起等待锁特点：

1. 一旦锁被释放，不能第一时间获取到
2. 在锁被其他线程占用的时候，会放弃 CPU 资源

synchronized 作为轻量级锁的时候，内部是自旋锁，作为重量级锁的时候，内部是挂起等待锁。

---

🏳️‍🌈五. 公平锁 vs 非公平锁

啥样的情况才算公平？
 
认为符合 “先来后到” 这样的规则，就是公平

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

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

注意：

• 操作系统内部对于挂起等待锁，就是非公平的(没有考虑先来后到)，如果想要使用公平锁就要搞额外的数据结构来进行控制实现
• 公平锁和非公平锁没有好坏之分, 关键还是看适用场景

synchronized 是非公平锁

---

🏴‍☠️六. 可重入锁 vs 不可重入锁

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

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

理解 “把自己锁死”

private static void func(){
   //第一次加锁
    synchronized (Demo26.class){
        //第二次加锁
        synchronized (Demo26.class){
             //...
        }
    }
}

按照之前对于锁的设定，第二次加锁的时候，就会阻塞等待，要等到第一次锁释放，这里的第二次加锁才能成功，但是第一次加锁释放不了，得第二次加锁成功代码继续往下走，才能走到第一次加锁的释放代码。

这就是个 “死锁！”。第二个锁加锁成功，依赖于第一个锁释放；第一个锁释放又依赖第二个锁加锁成功。

为了避免上述情况，就引入了 “可重入锁”，一个线程，可以对同一个锁，反复加锁多次，也没事！

可重入锁，在内部记录了这个锁是哪个线程获取到的，如果发现当前加锁的线程和持有锁的线程是同一个，则不挂起等待，而是直接获取到锁。同时还会给锁内部加上个计数器，记录当前是第几次加锁了，通过计数器来控制啥时候释放锁。

synchronized 也是可重入锁