Java中的锁策略与CAS以及死锁的成因与解决办法

淩亂°似流年 2024-03-24 14:29 53阅读 0赞

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

*  前言
 *  1. 锁的种类
 *  2. 锁策略
 *   *  2.1 锁升级
     *  2.2 锁消除
     *  2.3 锁粗化
 *  3. CAS
 *   *  3.1 CAS实现原子类
     *  3.1.1 CAS中的aba问题
     *  3.2 CAS实现自旋锁
 *  4. 死锁
 *   *  4.1 死锁形成的几种情况
     *  4.2 死锁的四个必要条件
     *  4.3 死锁的解决办法

## 前言 ##

由于加锁是一个开销较大的行为，为了更好的运用锁，我们对锁进行分类，以便于在不同的情况下使用。

## 1. 锁的种类 ##

1.  **乐观锁与悲观锁**
    
    1.  乐观锁：假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生**并发冲突**进行检测，如果发现并发冲突了，则让返回用户错误的信息，让用户决定如何去做。
    2.  悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
2.  **重量级锁与轻量级锁**  
    锁的核心特性“原子性”，主要是依赖于CPU硬件设备提供。**首先CPU 提供了 “原子操作指令”。操作系统基于 CPU 的原子指令, 实现了 mutex 互斥锁。JVM 基于操作系统提供的互斥锁, 实现了 synchronized 和 ReentrantLock 等关键字和类**
    
    1.  重量级锁：对于重量级锁来说，就过多的依赖于OS提供的mutex，以至于涉及大量的内核态与用户态的交换，并且会引发线程的调度，成本较高。
    2.  轻量级锁 ：对于轻量级锁来说，加锁机制尽可能不使用mutex，而是在用户态代码完成，此时我们的内核态用户态切换较少，也不太容易引发线程调度，成本较低。
3.  **公平锁与非公平锁**
    
    1.  对于公平与非公平的定义就是，看得到锁的顺序是否按先来后到的规则进行，如果遵守先来后到则是公平锁，不遵守就是非公平锁。
4.  **自旋锁与挂起等待锁**  
    按之前的方式，线程在抢锁失败后进入阻塞状态，放弃 CPU，需要过很久才能再次被调度。
    
    1.  自旋锁：对于自旋锁来说，就不会放弃 CPU 而是不断地重复尝试获取锁，直到获取锁为止，这样只要锁被释放就能最早的获取到。但是这种行为如果锁距离释放的时间久，就会持续消耗CPU资源。
    2.  挂起等待锁： 如果尝试获取锁失败就不会重复去获取，而是放弃CPU资源，挂起等待CPU调度。这种情况就可能不会第一时间拿到锁，但是不会消耗CPU资源。
5.  **互斥锁与读写锁**
    
    1.  互斥锁：一个线程拿到锁之后，另一个线程不能使用这是锁的基本特点。比如synchronized关键字，进入代码块加锁，出代码块解锁。
    2.  读写锁：当我们只是多个线程读同一个变量时，这个时候不涉及线程安全问题。此时直接互斥锁就会造成性能损耗，所以这种情况下就诞生来读写锁。  
        **约定：**  
        1.读锁与读锁之间不会锁竞争，不会产生阻塞等待。  
        2.写锁与写锁之间会锁竞争。  
        3.读锁与写锁之间也有锁竞争。
6.  **可重入锁与不可重入锁**  
    1. 可重入锁是允许同一个线程多次获取同一把锁。可重入锁也叫做递归锁。  
    2. 不可重入锁不允许同一个线程多次获取同一把锁，会发生锁竞争，阻塞等待。  
    **注意：** Java里只要以Reentrant开头命名的锁都是可重入锁

**对synchronized的总结：**

1.  开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
2.  开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁（参考后面的锁升级策略）。
3.  实现轻量级锁的时候大概率用到的自旋锁策略。
4.  是一种不公平锁。
5.  是一种可重入锁。
6.  不是读写锁，是互斥锁。

## 2. 锁策略 ##

在Java中实现加锁操作主要通过synchronized关键字和JUC包下的Lock接口，Lock 是JDK1.5之后引入的线程同步工具 。接下来以**synchronized**为例，解释以下三种锁优化策略：锁升级、锁消除、锁粗化。

### 2.1 锁升级 ###

1.  无锁：**synchronized** 在加锁的过程中并不是直接给锁对象加锁。
2.  偏向锁：第一个尝试加锁的线程，刚开始没有其他线程来竞争锁，就只给锁对象的对象头加一个偏向锁的标记，记录这个锁属于那个线程。
3.  自旋锁：当此时如果有其他线程也要对此时同一个对象加锁，也会先尝试加偏向锁，此时发现已经有线程加了偏向锁标记，此时jvm就会通知加标记的线程锁升级。此时就是真正的加锁，加轻量级锁，一般由自旋锁实现。
4.  重量级锁：当有许多线程都要来对同一个对象加锁时，此时会有许多自旋锁消耗大量cpu资源，所以此时可以直接升级为重量级锁，挂起等待之后的CPU调度。

### 2.2 锁消除 ###

以上讲的偏向锁是程序运行时，jvm做的优化，锁消除则是编译期间，检测当前代码是否需要加锁，如果不加锁但是写了加锁就在编译期间直接消除。  
比如我们的**StringBuffer**类中的关键方法都加了synchronized关键字，当我们在单线程使用时就不需要锁，此时编译器检测到了就会帮我们消除锁。

### 2.3 锁粗化 ###

**锁粒度：** 指的是我们synchronized修饰的代码块中的代码多少，如果代码越多锁的粒度就越大，代码越少锁的粒度就越小。  
我们是不希望频繁的加锁解锁的，会消耗大量资源，所以当我们锁粒度很小时，隔几行代码就有一个锁，此时编译器就会把它优化成一个粒度更大的锁，也就是直接整体加锁，此时就是锁粗化策略。

## 3. CAS ##

**什么是CAS？**  
CAS全称Compare and swap，字面意思:”比较并交换“，一个 CAS 涉及到以下操作：

> 我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。
> 
> 1.  比较 A 与 V 是否相等。（比较）
> 2.  如果比较相等，将 B 写入 V。（交换）
> 3.  返回操作是否成功

**CAS的伪代码实现：**

boolean CAS(address, expectValue, swapValue) {
        
    if (&address == expectedValue) {
        
    &address = swapValue;
    return true;
    }
    return false;
    }

注意： 以上代码只是形象的解释我们CAS的底层工作原理，实际上CAS是CPU上的一条原子指令。

**为什么有CAS？**  
由于CAS只用一条CPU指令，可以实现对变量值的更改，此时我们就可以用它实现原子类，不加锁就能保证线程安全。同样的CAS还能用来实现自旋锁。

### 3.1 CAS实现原子类 ###

Java标准库中提供了 java.util.concurrent.atomic 包, 里面的类都是基于CAS来实现的。典型的就是 AtomicInteger 类。其中的getAndIncrement 相当于 i++ 操作，这个时候不加锁就能保证原子性实现多线程自增操作。  
**伪代码实现：**

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

**解读：** value是需要自增的变量，理解为内存中存储的值。oldValue可以视为寄存器，进入循环判断，寄存器的值是否是等于要自增的变量的值，如果是的，就说明修改不会出现问题，就将寄存器的值加1赋给value，循环结束。如果不等于，就说明此时该变量被别的线程修改了但是还没有记录到寄存器，此时就重新设置oldVlue的值，直到相等时，就说明可以自增了。

**简而言之：此处的CAS就是为了确定当前的value是否变过，如果没有改变就可以直接自增，如果改变了就需要先更新再自增。**

要想更加理解这个问题可以参考我的另一篇博客[线程不安全的几种情况与解决办法][Link 1]，里面有关于原子性以及内存可见性的解说。

### 3.1.1 CAS中的aba问题 ###

由于以上我们可以知道，CAS通过比较内存与寄存器中的值是否相等来判断，这个内存是否改变过。但是会出现一种情况，就是我们的值虽然相等，但是我们并不是没有改变过，而是从**a->b->a**。  
此时就有一定概率出现问题。

**举个例子：** 假设我们有100块钱，打算取50块钱。如果我们取款机创建两个线程来并发执行扣50的操作。  
1）线程1获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50。  
2) 线程1 执行扣款成功, 存款被改成 50。 线程2 阻塞等待中。  
3) 轮到线程2 执行了, 发现当前存款为 50, 和之前读到的 100 不相同, 执行失败。  
但是如果此时有一个线程3向我转账，此时存款从50修改成了100，线程2再执行时发现存款还是100。就会进行-50，**此时就会进行两次扣款。**

**如何解决aba问题？**

1.  第一种情况，我们可以规定数据只能单方向变化，也就是只能增加或者减少，这个时候就不会出现a->b->a.
2.  第二种情况，引入一个版本号变量，约定版本号只能增加，每次CAS对比的时候不再是对比值，而是对比版本号，此时就能保证数据既可以增加又可以减少，同时可以通过版本号来确定数据是否改变。

### 3.2 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;
    }
    }

## 4. 死锁 ##

### 4.1 死锁形成的几种情况 ###

**死锁：** 当多个线程同时被阻塞，线程中的一个或者多个又或者全部都在等待某个资源被释放，造成线程无限期的阻塞，导致程序不能正常终止就叫做死锁。

1.  **一个线程对一个对象加两次锁**，此时如果是可重入锁就不会发上死锁，如果是不可重入锁就会发生死锁。
2.  **两个线程两把锁**，如以下代码，t1线程先对locker1加锁，t2线程先对locker2加锁，接下来t1需要对locker2加锁，由于此时t2线程对locker2加锁，所以t1线程获取不到locker2的锁，必须得t2释放，又由于t2线程需要执行完获取locker1的锁才能释放，此时就会僵持不下，造成死锁阻塞。  
    ![在这里插入图片描述][c6372284b4b041d6b6a9d6960ee994b4.png]
3.  **N个线程M把锁**，典型的情况哲学家就餐问题。
    
    1.  问题描述：  
        有五个哲学家围在一张圆桌，分别坐在周围的五张椅子上，在圆桌上有五个筷子，他们的生活方式是交替的进行思考和进餐。平时，一个哲学家进行思考，饥饿时便试图取用其左右最靠近他的筷子，只有在他拿到两支筷子时才能进餐。进餐完毕后，放下筷子继续思考。我们认为筷子是锁，一个哲学家是一个线程。  
        2. 当我们每个哲学家都拿起左边的筷子时，此时就会出现每个哲学家都在等待右边的筷子，然后都不能进餐，此时就是死锁。

### 4.2 死锁的四个必要条件 ###

1.  互斥使用，所得基本特点。
2.  不可抢占，一个线程拿到锁之后，只能自己主动释放，不能被其他线程强行占有。
3.  请求和保持，当资源请求者在请求其他的资源的同时保持对原有资源的占有，例如以上死锁的第二种情况。
4.  循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路，比如以上的哲学家就餐问题，每一个人都等待着旁边一个人放下筷子。

### 4.3 死锁的解决办法 ###

由以上死锁的必要条件可以看出，我们解除死锁最容易破坏的条件就是循环等待。

**破坏循环等待：**

最常用的一种死锁阻止技术就是锁排序. 假设有 N 个线程尝试获取 M 把锁, 就可以针对 M 把锁进行编号(1, 2, 3…M)。N 个线程尝试获取锁的时候, 都按照固定的按编号由小到大顺序来获取锁.。这样就可以避免环路等待。

**举例：**

1.  比如上述死锁的第二种情况我们对locker1，locker2，编号，1，2并约定，按编号从小到大顺序取锁，此时就不会出现死锁。  
    代码演示：

Object lock1 = new Object();
    Object lock2 = new Object();
    Thread t1 = new Thread() {
        
    @Override
    public void run() {
        
    synchronized (lock1) {
        
    synchronized (lock2) {
        
    
    }}}};
    t1.start();
    Thread t2 = new Thread() {
        
    @Override
    public void run() {
        
    synchronized (lock1) {
        
    synchronized (lock2) {
        
    }}}};
    t2.start();

1.  对于哲学家就餐问题我们可以·让他们每次取两边编号小的筷子就餐。此时2号老铁取了1筷子，3取2筷子，4取3筷子，5取4筷子，1号老铁此时就应该取1号筷子但是由于1号在使用，所以就等待，此时5号老铁就能再取上5号筷子，然后吃饭，放下筷子后，4号老铁此时也能拿起另外一只筷子，以此类推，所有的哲学家就都能吃上饭。  
    ![在这里插入图片描述][47c4e5c9fe944812be0ccbdc2888a761.png]

[Link 1]: http://t.csdn.cn/M6b16
[c6372284b4b041d6b6a9d6960ee994b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/96a55bcd9ce54112b516791b3042247d.png
[47c4e5c9fe944812be0ccbdc2888a761.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/e08435a3bbba41bb96e704bdb88f5932.png