【多线程】常见的锁策略

心已赠人 2024-04-08 11:57 83阅读 0赞

#### 文章目录 ####

*  1. 乐观锁 VS 悲观锁
 *  2. 读写锁
 *  3. 重量级锁 VS 轻量级锁
 *  4. 自旋锁 VS 挂起等待锁
 *  5. 公平锁 VS 非公平锁
 *  6. 可重入锁 VS 不可重入锁

## 1. 乐观锁 VS 悲观锁 ##

<table> 
 <thead> 
  <tr> 
   <th>锁策略</th> 
   <th>说明</th> 
   <th>实现</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>乐观锁</td> 
   <td>认为锁冲突是小概率事件，假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。</td> 
   <td>引入一个版本号，借助版本号识别出当前的数据访问是否冲突，如果冲突则将数据更新。</td> 
  </tr> 
  <tr> 
   <td>悲观锁</td> 
   <td>认为锁冲突是大概率事件，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。</td> 
   <td>先加锁（比如借助操作系统提供的 mutex），获取到锁再操作数据们获取不到就等待。</td> 
  </tr> 
 </tbody> 
</table>

乐观锁和悲观锁并无高下之分，主要还是看应用场景。

synchronized 既是一个乐观锁，又是一个悲观锁。能够根据实际场景，自动进行适应。

*  当锁冲突概率比较低时，synchronized 内部就是以乐观锁策略实现的。
 *  当锁冲突概率比较高时，synchronized 内部就是以悲观锁策略实现的。

## 2. 读写锁 ##

读写锁就是把读操作和写操作分别加锁，适用于读多写少的场景中，Java 标准库提供了 `ReentrantReadWriteLock` 类，该类实现了读写锁：

<table> 
 <thead> 
  <tr> 
   <th>锁策略</th> 
   <th>实现类</th> 
   <th>补充</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>读锁</td> 
   <td><code>ReentrantReadWriteLock.ReadLock</code></td> 
   <td>这个对象提供了 lock/unlock 方法进行加锁和解锁。</td> 
  </tr> 
  <tr> 
   <td>写锁</td> 
   <td><code>ReentrantReadWriteLock.WriteLock</code></td> 
   <td>这个对象提供了 lock/unlock 方法进行加锁和解锁。</td> 
  </tr> 
 </tbody> 
</table>

其中读锁和写锁之间的关系如下：

*  读锁和读锁之间，不互斥
 *  写锁和写锁之间互斥
 *  读锁和写锁之间互斥

synchronized 不是读写锁。

## 3. 重量级锁 VS 轻量级锁 ##

锁的核心特性原子性，追根溯源是 CPU 这样的硬件设备提供的：

*  CPU 提供了原子操作指令
 *  操作系统基于 CPU 的原子指令，实现了 `mutex` 互斥锁
 *  JVM 基于操作系统提供的互斥锁，实现了 synchronized 和 ReetrantLock 等关键字和类来进行加锁。

<table> 
 <thead> 
  <tr> 
   <th>锁策略</th> 
   <th>说明</th> 
   <th>特点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>重量级锁</td> 
   <td>加锁机制重度依赖了 OS 提供的 mutex</td> 
   <td>涉及到了大量的内核态和用户态的切换，易引发线程的调度。</td> 
  </tr> 
  <tr> 
   <td>轻量级锁</td> 
   <td>加锁机制尽可能不使用 mutex，而尽量在用户态代码完成，实在搞不定了才使用mutex</td> 
   <td>很少会涉及内核态和用户态的切换，不容易引发线程调度</td> 
  </tr> 
 </tbody> 
</table>

*  synchronized 开始是一个轻量级锁，如果锁冲突比较严重，就会变成重量级锁。
 *  synchronized 内部的轻量级锁是基于自旋的方式实现的，重量级锁是基于挂起等待的方式实现的。

## 4. 自旋锁 VS 挂起等待锁 ##

<table> 
 <thead> 
  <tr> 
   <th>锁策略</th> 
   <th>说明</th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>自旋锁</td> 
   <td>如果获取锁失败，就会立即再次获取锁，循环下曲直到获取到锁为止</td> 
   <td>没有放弃 CPU，不涉及到线程阻塞和调度，一旦锁被释放，就能第一时间获取到锁</td> 
   <td>如果锁被其他线程持有的时间比较久，那就就会持续消耗 CPU 资源</td> 
  </tr> 
  <tr> 
   <td>挂起等待锁</td> 
   <td>如果获取锁失败，就会挂起等待，会放弃 CPU，进入内核的阻塞队列，直到锁被释放且 CPU 调度到该线程</td> 
   <td>节省 CPU 资源</td> 
   <td>速度比较慢，一旦锁释放不能够第一时间直到</td> 
  </tr> 
 </tbody> 
</table>

*  自旋锁可以认为是轻量级锁的一种典型实现，也可以认为是乐观锁的一种典型实现。
 *  挂起等待锁可以认为是重量级锁的一种典型实现，也可以认为是悲观锁的一种典型实现。
 *  sunchronized 开始是自旋锁，后面锁竞争激烈了就变成了挂起等待锁。

## 5. 公平锁 VS 非公平锁 ##

如果有 A、B、C 三个线程，A 线程在获取到锁后，B 紧接着获取锁但失败了，C 最后也获取锁也失败了。当 A 释放锁后，如果按照先来后到的顺序获取锁，即 B 先获取锁，则是一个公平锁。如果不遵循先来后到，B 和 C 都有可能获取锁，则是一个非公平锁，

<table> 
 <thead> 
  <tr> 
   <th>锁策略</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>公平锁</td> 
   <td>遵循先来后多</td> 
  </tr> 
  <tr> 
   <td>非公平锁</td> 
   <td>不遵循先来后到，随即调度</td> 
  </tr> 
 </tbody> 
</table>

*  操作系统内部的线程调度可以视为是随机的，如果不做额外的限制，锁就是非公平锁。如果要实现公平锁，则需要依赖额外的数据结构来记录线程的先后顺序。
 *  synchronized 是非公平锁。

## 6. 可重入锁 VS 不可重入锁 ##

<table> 
 <thead> 
  <tr> 
   <th>锁策略</th> 
   <th>说明</th> 
   <th>实现</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>可重入锁</td> 
   <td>允许同一个线程多次获取同一把锁</td> 
   <td>在锁中记录锁持有的线程的身份，以及一个计数器（记录加锁的次数），如果当前加锁的线程就是持有锁的线程，则直接计数自增。</td> 
  </tr> 
  <tr> 
   <td>不可重入锁</td> 
   <td>不允许同一个线程多次获取同一把锁</td> 
   <td></td> 
  </tr> 
 </tbody> 
</table>

*  Java 里只要以 Reentrant 开头命名的锁就是可重入的，而且 JDK 提供的所有现成的 Lock 实现类，包括 synchronized 关键字都是可重入的。
 *  Linux 系统提供的 mutex 是不可重入锁。
 *  不可重入锁会产生死锁操作（即同一线程加锁后，在没释放锁之前又进行加锁，那么此时由于是不可重入锁，该线程则会阻塞等待，但是线程又需要释放锁了才能解除当前状态，所以就会死锁）。
 *  synchronized 是可重入锁。