常见的锁策略

妖狐艹你老母 2023-09-27 13:52 91阅读 0赞

![在这里插入图片描述][84ba1c1e5c0047bbb75f35bc1c67cc8b.gif_pic_center]

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

*  一、常见的锁策略
 *   *  乐观锁 vs 悲观锁
     *  轻量级锁 vs 重量级锁
     *  自旋锁 vs 挂起等待锁
     *  互斥锁 vs 读写锁
     *  公平锁 vs 非公平锁
     *  可重入锁 vs 不可重入锁
 *  二、CAS
 *   *  原子类
     *  实现自旋锁
     *  ABA问题

## 一、常见的锁策略 ##

我们这里所介绍到的锁策略，不仅仅是java中的，任何涉及到锁的地方，比如数据库，操作系统等等，都会设计到以下特性

### 乐观锁 vs 悲观锁 ###

**乐观锁**: 认为锁竞争不是很激烈(做的工作更少，开销更小)  
**悲观锁**: 认为锁锁竞争比较激烈(做的工作更多，开销更大)

举个例子: 你想要去你朋友家找你朋友玩。  
有两种做法: 1. 你认为你朋友是比较忙的，不一定在家。所以你会先向你朋友发消息确认一下你朋友在家吗，我来找你玩？(相当于加锁)，如果在家就去找，如果不在家就等一段时间，在向朋友确定时间，这是悲观锁  
2. 你认为你朋友是比较闲的，大概率是在家的，所以你会直接去你朋友家（没有加锁，直接访问资源),如果确实在家，目的就达成了，如果不在家，下次再来(尽管没加锁，但能识别数据访问冲突),这是乐观锁。

这两种锁策略，不能去分个高度，只能说不同的场景，有不同的用处。

**我们的Synchronized初始使用乐观锁，当发现锁竞争比较频繁的时候，就会自动切换为悲观锁。**  
我们乐观锁有一个很重要的功能，就是要检测数据访问是否冲突，我们这里引入一个: "版本号"来解决。

比如两个线程去操作一个共享数据A初始为50，版本号为001，规定版本号的提交版本必须大于记录版本号才能更新操作。  
![在这里插入图片描述][7b572f30d696466b9e99393d687c84c6.png]  
比如我们的线程一将A修改为100，然后提交版本号为002，当我们的线程二将A修改为80时，修改版本号为002提交时，我们发现版本号并没有大于记录版本号，所以我们就认为此次的操作失败。  
![在这里插入图片描述][d0026614371040d5b6a726962ab128b0.png]

### 轻量级锁 vs 重量级锁 ###

我们锁的核心特性: “原子性”,这样的机制追溯到根源是CPU硬件设备提供的  
1.CPU提供了"原子操作指令”  
2.操作系统基于CPU原子指令，实现了mutex互斥锁  
3.JVM基于操作系统提供的互斥锁，实现了synchronized和reentrantLock等关键字和类  
**轻量级锁**: 轻量级锁的加锁解锁的开销比较小(加锁尽量不使用mutex，而是尽量在用户态(我们人为可控制的状态)代码完成，实在完成不了在使用mutex)  
**重量级锁**: 重量级锁的加锁解锁的开销比较大(加锁严重依赖操作系统的mutex，大量的内核态用户态的切换，线程调度的开销)  
大多数情况下，乐观锁也是一个轻量级锁。  
大多数情况下，悲观锁也是一个重量级锁。

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

**自旋锁(Spin Lock)**：在线程抢锁失败后，不是阻塞等待，而是快速的再循环一次，一旦锁被其他线程释放，就能第一时间获取到锁  
**挂起等待锁**: 往往是内核实现，线程在抢锁失败之后进入阻塞状态，不占用CPU，直到操作系统调度之后被唤醒。

//自旋锁的伪代码
    while(获取锁() == 失败) {
        
    }

逻辑比较简单，先去获取锁，如果获取失败，就无限循环，直到获取到锁为止，一旦其他线程释放锁，会第一时间获取到锁。

自旋锁是一种典型的轻量级锁的实现方式:  
**优点**: 没有放弃CPU，不涉及线程阻塞和调度，锁一旦被释放，就能第一时间获取到锁  
**缺点**: 如果锁被占用的时间较长，那么自旋锁就会持续占有消耗CPU资源(我们挂起等待的状态是不消耗CPU资源的。

**synchronized中的轻量级锁策略就很有可能是通过自旋锁方式实现的。**

### 互斥锁 vs 读写锁 ###

**互斥锁**: 我们之间用到过的synchronized这样的锁，如果一个线程获取到了锁，其他线程也尝试加锁的话，就会阻塞等待。  
**读写锁**: 我们在并发编程的时候，如果仅仅是多个线程去读一个共享变量是不会产生线程安全问题的，但写和读之间或者写和写之间是互斥的。如果我们所有场景都使用同一种锁，就会产生很大的性能消耗，因此我们需要把读写锁分开。  
读写锁就是把读操作和写操作分别加锁，我们java标准库提供了ReetrantReadWriterLock类，分别实现了读写锁。  
ReentrantReadWriteLock.ReadLock 类表示一个读锁. 这个对象提供了 lock / unlock 方法进行加锁解锁.  
ReentrantReadWriteLock.WriteLock 类表示一个写锁. 这个对象也提供了 lock / unlock 方法进行加锁解锁

我们所有的锁策略并没有优劣之分，我们的**synchronized是互斥锁**,我们的读写锁适合于"高频读，低频写"这样的场景。

### 公平锁 vs 非公平锁 ###

我们来举例说明下公平锁和非公平锁。  
我们有三个人在图书馆等开门。  
![在这里插入图片描述][58f54f0e8cec4c7d9dcb993f14ab1c4f.png]  
我们的公平锁就是，最先来的先进，按顺序进。  
![在这里插入图片描述][6789cf879f7747a8bf8e43ff28620b57.png]  
非公平锁，就是三个人抢着给进冲，谁先进到图书馆，充满不确定性。  
![在这里插入图片描述][5dde45c4e91045d9b7b0726a4c3ce54a.png]  
我们操作系统内部的线程调度可以认为是随机的，如果没有任何干涉，就是非公平锁。如果想要实现公平锁，需要加额外的数据结构(比如队列)，来记录线程的先后顺序。

**synchronized是非公平锁**

### 可重入锁 vs 不可重入锁 ###

**可重入锁**: 一个线程针对同一把锁连续加锁两次，不会出现死锁  
**不可重入锁**: 一个线程针对同一把锁连续加锁两次，会出现死锁

按照我们之前对于锁的设定，当我们第二次加锁的时候，就会阻塞等待，直到第一次的锁被释放，才能获取到第一把锁，但是我们的第一个锁的释放也是由该线程完成，但是该线程正在尝试加锁，也就无法进行解锁操作，就会产生死锁。我们synchronized内部做了处理，判断时候第一次加锁和第二次加锁是同一个线程就不会产生死锁。

我们java当中**synchronized是可重入的**，以及Reentrant开头命名的锁都是可重入的，但是我们操作系统提供的mutex是不可重入锁。

## 二、CAS ##

CAS(Compare and swap)：比较并交换，简单的来说就是CAS通过一条CPU指令(原子操作)在一定程度上可以回避线程安全问题，这是加锁之外，另一种解决线程安全的思路.  
我们的CAS大致思路:  
![在这里插入图片描述][1f9aedd7e6c54d4d9393a4dd699ebcbf.png]  
这里的old是我们内存的原数据，new是我们旧的预期值，expect是我们需要将旧的值改为的值。  
1.先比较 old 和 new是否相等(比较）  
2.如果相等，将expect赋给old，否则什么都不发生(交换)  
3.返回操作是否成功

//CAS伪代码，并非真实
    boolean CAS(address, expectValue, swapValue) {
        
     if (&address == expectedValue) {
        
       &address = swapValue;
            return true;
       }
        return false;
    }

我们上述代码只是CAS大致思路，并不是原子的，真正的CAS是通过CPU指令完成的，硬件给予了支持，我们的软件层面才达到了此行为。

### 原子类 ###

我们的JUC包下为我们提供了一些原子类，就是通过CAS的方式实现的。  
![在这里插入图片描述][a4b96b56bea946dba853375fcb08489c.png]

<table> 
 <thead> 
  <tr> 
   <th>方法</th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>addAndGet(int delta)</td> 
   <td>i += delta</td> 
  </tr> 
  <tr> 
   <td>decrementAndGet()</td> 
   <td>–i</td> 
  </tr> 
  <tr> 
   <td>getAndDecrement()</td> 
   <td>i–</td> 
  </tr> 
  <tr> 
   <td>incrementAndGet()</td> 
   <td>++i</td> 
  </tr> 
  <tr> 
   <td>getAndIncrement()</td> 
   <td>i++</td> 
  </tr> 
 </tbody> 
</table>

我们举例说明是如何保障线程安全的，我们这里以AtomicInteger的getAndIncrement()方法为例:

class AtomicInteger {
        
        private int value;
        public int getAndIncrement() {
        
            int oldValue = value;
            while ( CAS(value, oldValue, oldValue+1) != true) {
        
                oldValue = value;
           }
            return oldValue;
       }
    }

我们的线程一，线程二根据同一个AtomicInteger对象A进行getAndIncrement()操作。  
![在这里插入图片描述][d3e189040a924047a66ad41ff18c29c9.png]  
我们线程一和线程二对A进行操作，线程一对A进行了CAS操作，先比较是否与内存的值是否相等，我们发现是相等的，于是进行getAndIncrement操作。  
![在这里插入图片描述][6d78e9dd280b4b4e8eaeed2692338095.png]  
当我们线程二进行getAndIncrement操作时，进行比较时发现与内存的值并不相同，于是它就会从新加载一份内存的值到自己的工作内存，然后在进行比较，比较相等在进行getAndIncremenet操作，如果不相等在加载，比较，一直循环到操作完成为止。

我们可以发现通过CAS的方式就可以实现一个原子类，而且不用使用重量级锁，就可以实现多线程对于共享变量的操作。

### 实现自旋锁 ###

我们在上述已经给大家已经介绍了自旋锁的情况，基于CAS能够更灵活的实现自旋锁

public class SpinLock {
        
        private Thread owner = null;
        public void lock(){
        
            // 通过 CAS 看当前锁是否被某个线程持有. 
            // 如果这个锁已经被别的线程持有, 那么就自旋等待. 
            // 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程. 
            while(!CAS(this.owner, null, Thread.currentThread())){
        
           }
       }
        public void unlock (){
        
            this.owner = null;
       }
    }

简单的来说我们的自旋锁需要判断锁是否空闲，如果空闲就获取，否则继续判断，直到获取为止，这和我们的CAS的比较，赋值干的活是一致的，所以我们的判断锁是否空闲，并且获取锁这一操作就可以基于CAS的操作来实现。

### ABA问题 ###

我们的CAS操作，大致流程就是判断old和new的值是否一致，如果一致，就认为这个变量是没有进行过操作，于是之间赋值。  
ABA这个问题，就相当于我们买苹果手机，确实我们是拆了新机，但我们拆的这个手机，可能是翻新机，也可能是新机，对于我们正常使用来讲是无法区分的。  
但是我们这里有一个非常极端的情况。  
![在这里插入图片描述][a0af388842d946e7bd0001df779eaefd.png]  
我们的狗头老铁去银行取钱，卡里总共有两百，想取100去网吧冲冲浪，于是他在自动取款机上按下了取100的操作，然后自动取款机卡死了，已经扣费了100，但是屏幕没有任何显示，也没有出钱，与此同时狗头老铁的好朋友给他还钱转了100，然后等了一会，然后自动取款机恢复了，狗头老铁发现余额是200，然后又输了取款100的操作，这次取款成功了。  
尽管这种情况的发生的概率是很低的，但是我们仍然需要防患于未然，针对这里的操作我们引入一个**版本号**的概念，比如我们进行CAS操作的时候，初始的版本号是001，每次发生变化是我们的版本号都加1，进行CAS操作时，去判断版本号，如果版本号没变，证明我们的变量是没有变化的，如果版本号变化了，证明我们的变量进行过修改。

[84ba1c1e5c0047bbb75f35bc1c67cc8b.gif_pic_center]: https://img-blog.csdnimg.cn/84ba1c1e5c0047bbb75f35bc1c67cc8b.gif#pic_center
[7b572f30d696466b9e99393d687c84c6.png]: https://img-blog.csdnimg.cn/7b572f30d696466b9e99393d687c84c6.png
[d0026614371040d5b6a726962ab128b0.png]: https://img-blog.csdnimg.cn/d0026614371040d5b6a726962ab128b0.png
[58f54f0e8cec4c7d9dcb993f14ab1c4f.png]: https://img-blog.csdnimg.cn/58f54f0e8cec4c7d9dcb993f14ab1c4f.png
[6789cf879f7747a8bf8e43ff28620b57.png]: https://img-blog.csdnimg.cn/6789cf879f7747a8bf8e43ff28620b57.png
[5dde45c4e91045d9b7b0726a4c3ce54a.png]: https://img-blog.csdnimg.cn/5dde45c4e91045d9b7b0726a4c3ce54a.png
[1f9aedd7e6c54d4d9393a4dd699ebcbf.png]: https://img-blog.csdnimg.cn/1f9aedd7e6c54d4d9393a4dd699ebcbf.png
[a4b96b56bea946dba853375fcb08489c.png]: https://img-blog.csdnimg.cn/a4b96b56bea946dba853375fcb08489c.png
[d3e189040a924047a66ad41ff18c29c9.png]: https://img-blog.csdnimg.cn/d3e189040a924047a66ad41ff18c29c9.png
[6d78e9dd280b4b4e8eaeed2692338095.png]: https://img-blog.csdnimg.cn/6d78e9dd280b4b4e8eaeed2692338095.png
[a0af388842d946e7bd0001df779eaefd.png]: https://img-blog.csdnimg.cn/a0af388842d946e7bd0001df779eaefd.png