devbox
小丑西瓜9
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

【JavaEE】多线程进阶问题-锁策略and死锁，CAS操作，Synchronized原理

作者：小丑西瓜9 | 2024-05-30 13:35:06

赞

踩

【JavaEE】多线程进阶问题-锁策略and死锁，CAS操作，Synchronized原理

文章目录

JavaEE & 多线程进阶问题 & 锁策略and 死锁，CAS操作，Synchronized原理

1. 锁策略

  • 不仅限于Java，其他语言也适用这套规则

1.1 乐观锁 vs 悲观锁

锁的实现者通过锁的冲突概率，做出相应的决策

  1. 乐观锁 ==> 预测接下来冲突概率小
    • 工作量更少，效率大
  2. 悲观锁 ==> 预测接下来冲突概率大
    • 工作量更多，效率小
  • 但是并不绝对。
  • 这里的工作量就是锁操作的内部一些操作

了解概念即可~

1.2 轻量级锁 vs 重量级锁

虽然和乐观锁悲观锁不是一回事，但是有部分概念重合~

  1. 轻量级锁 ==> 加锁解锁更快更高效
  2. 重量级锁 ==> 加锁解锁更慢更低效
  • 轻量级锁很可能是乐观锁
  • 重量级锁很可能是悲观锁
    • 但是不绝对~

1.3 自旋锁 & 挂起等待锁

这跟轻重锁有密切联系

  1. 自旋锁 ==> 轻量级锁的典型实现
  2. 挂起等待锁 ==> 重量级锁的典型实现

对于自旋锁：

  • 对于遇到锁冲突，并没有选择等待，而是没闲着，反复确认是否锁被释放
    • 这样子做虽然精度高，但是消耗CPU资源大，即忙等
    • 重量级锁这样会，导致其他任务受限，得不偿失~

在这里插入图片描述

对于挂起等待锁

  • 对于遇到锁冲突，直接中断任务，等待锁释放
    • 这样子做虽然精度不高，但是可以让CPU去干其他的任务
    • 轻量级锁这样做，可能会导致轻量级锁的任务不能满足更精的要求

在这里插入图片描述

  1. 自旋 ==> 纯用户态操作，不需要经过内核态，时间相对更短

    • 轻量

  2. 挂起等待 ==> 需要通过内核的机制来实现挂起等待，时间相对更长

    • 重量

1.4 synchronized属于哪种锁？

  • synchronized即是乐观锁又是悲观锁，即是轻量级锁，又是重量级锁
    • 轻量级部分基于自旋锁实现
    • 重量级部分基于挂起等待锁实现
  • 感觉情况，变化，自适应
  1. 如果锁冲突不激烈，以轻量级锁/乐观锁去适应
  2. 如果锁冲突很激烈，以重量级锁/悲观锁去适应
    • 尽可能节省地，保证线程安全~
  • 没错，JVM就是这么牛

1.5 互斥锁 vs 读写锁

  • synchronized是互斥锁，就只是单纯加锁，没有更细化的部分~
    1. 加锁
    2. 释放锁

对于读写锁：

  1. 对读加锁
  2. 对写加锁
  3. 释放锁

读写锁约定：

  1. 读锁和读锁之间，不会产生锁竞争 — 多线程读操作，线程安全~

  2. 写锁和写锁之间，就会产生锁竞争

  3. 读锁和写锁之间，也会产生锁竞争

【非必要不加锁】，适用于一写多读的情况

虽然synchronized并非读写锁，但是Java标准库有~

  • 在特定的场景下可以使用~

ReentrantReadWriteLock的源码发现,

其内部含有ReadLock和WriteLock这两个类,

代表ReentrantReadWriteLock拥有的一对读锁 和写锁,

在这里插入图片描述

1.6 公平锁 vs 非公平锁

  • 规定：遵守先来后到称为公平锁，不遵守先来后到称为非公平锁
    • 可能我们直观的想法是，抢到锁的概率是否一样来觉得公平不公平~
    • 而这个规定就是发明这个概念的大佬定下来的~
  • 就是，一个锁被一个线程抢了，而其他线程都在等待，但是等的时间不一样

在这里插入图片描述

  • 而如果是非公平锁，只要锁释放，线程234都有可能抢到锁

    • 即线程4这个刚来的可能会比其他两个线程之快抢到锁~

  • 而如果是公平锁，锁释放后，按照先后顺序分配锁

    • 即线程 3 2 4顺序

  • 实现公平锁的话，加个队列记录顺序即可~

2. 死锁

2.1 可重入锁 vs 不可重入锁

  • 对于一个线程，针对同一把锁，连续加锁两次
    • 出现死锁了，就是不可重入锁
    • 不出现死锁，就是可重入锁

对于不可重入锁：

  • 同一把锁：同一锁对象

在这里插入图片描述

  • 举个栗子：
    • 还有个栗子，疫情期间，一些店铺要求你进店铺需要带口罩，而你如果没有口罩想进去买口罩呢？

在这里插入图片描述

日常开发是很容易触发这些代码的，例如：

synchronized void A() {
    ·······
}

  • 1
  • 2
  • 3
  • 这是一个被锁住的方法
synchronized void B() {
    A();
    ·······
}

  • 1
  • 2
  • 3
  • 4
  • 在同一个类之中的另一个锁方法，调用A方法

这样，就会出现，一个线程对同一把锁的，连续加锁两次~

然而，出现这些情况就会触发死锁bug吗？

  • 显然是不会的，synchronized就是可重入锁

    • synchronized会识别，竞争的锁是否本就被自己“抢到”，如果是，就不需要阻塞等待~
    • 即会判断自己是否是锁的拥有者

  • 没错，JVM就是这么牛

2.2 两个线程两把锁

  • 对于这种情况，即使是可重入锁，也会死锁~

在这里插入图片描述

  • 当然，若线程1或者线程2进入第二层锁，那么另一个线程也不会进入第一层锁，这样也不会出现死锁
  • 但是，线程调度无序性呀，出现同时进入第一层锁是很有可能的！

在这里插入图片描述

  • 所以就出现相互限制的情况！

在这里插入图片描述

2.3 N个线程，M把锁

  • 线程越多，锁越多，更容易出现死锁情况了~
2.3.1 哲学家就餐问题

在这里插入图片描述

  • 那么就会出现如下情况：

假设五个哲学家，同时拿起左手边的筷子，那么他们就会固执的嗦不了粉

  • 因为，他们在等待别人放下筷子~
  • 而这里的别人也在等他们自己放下筷子~

在这里插入图片描述

  • 由此可见，线程越多，锁越多，更容易出现死锁情况了~
2.3.2 死锁的基本特点，四个必要条件
  1. 互斥使用
  2. 不可抢占，一个锁只能由锁的拥有者自行释放，不能强行占用~
  3. 请求和保持，（去抢别的锁，但是却没有释放原本的锁）
  4. 循环等待，（逻辑形成循环）

四个条件缺一不可！

  • 1和2是锁的基本特点
  • 而3和4，代码的特点
    • 就是哲学家就餐问题的根本原因！
2.3.3 死锁的处理

死锁是一个很严重的bug，我们要如何处理呢？

  • 有很多方法可以处理
  • 而在开发中，最实用简单的就是：【按顺序加锁】

其实，死锁的产生就是因为加锁链是交叉的

例如，两个线程两把锁：

在这里插入图片描述

  • 交叉代表了，
    • 可能会互相影响！
    • 锁内部要抢的锁，可能会被别人抢走，进而导致我无法释放锁，别人无法获得我的锁

依照这个思路，我们只需要规定一个顺序，只要一层层加锁的时候，都严格按照同一个顺序来加锁，就可以巧妙的防止出现交叉，防止死锁的出现！

  • 注意，这里只需要都满足一个顺序就行，并不是要按照锁编号大小顺序~
  • 给锁编号，方便排序管理~

例如以下的，四个线程，四把锁

  • 都按照1234
    • 不会导致交叉，即不会死锁

在这里插入图片描述

  • 若其中有线程不满足！
    • 就会导致交叉，即有可能会死锁！

在这里插入图片描述

总结就是，注意写代码时，按照加锁顺序！！！

  1. 【两个线程两把锁】解决：

在这里插入图片描述

  1. 【哲学家就餐问题】解决：
  • 首先，对筷子进行编号：

在这里插入图片描述

  • 约定，哲学家只能先拿编号小的筷子，才能拿编号大的筷子
    • 【外提一嘴，对于这种实际问题，我觉得哲学家太固执了，估计也不会遵循】

那么，无论谁先开始拿（随机调度）

  • 最终，至少会导致一个哲学家拿不到一根筷子，

  • 那么就至少会有一个哲学家拿到两根筷子！

那么的那么，这个哲学家嗦完粉后，就可以放下筷子，这样其他等待的哲学家就可以嗦粉了

  • 并且，之后的过程，也不会产生“死锁现象”
  • 这样，原本死锁的问题被巧妙的破解了~

在这里插入图片描述

  • 以此类推，不会出现死锁！程序正常执行~

3. CAS操作

3.1 CAS介绍

CAS ==> Compare-And-Swap

即，比较 和 交换

作用就是：

boolean CAS(M, A, B)

  • M为内存地址，A和B为寄存器的值
  1. 发现M对应的值与A相等，则交换B和内存M对应的值，返回true
    • B可能也来自另一个内存，不好说~
  2. 发现M对应的值与A不同，啥也不做，则返回false

对于这个操作，我们更关心，M对应的值被赋值~

  • 下面为CAS的伪代码~
boolean CAS(M, A, B) {
    if (*M == A) {
        *M = B;
        return true;
   	}
    return false;
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

重点：

  • CAS并不是上述描述的一段伪代码
  • 而是单一的一条原子的CPU指令！！！
    • 不存在线程安全问题~

意义：打开新世界大门，不加锁也能线程安全！

  • 当然，CAS操作需要有CPU的支持~
  • 由JVM封装，我们的CPU也可以做CAS操作了

3.2 CAS操作实现原子类

  • Java标准库提供了很多原子类
    • AtomicXXX，原子的XXX

在这里插入图片描述

3.2.1 AtomicInteger类
  • 这是一个原子普通类
    • 可以保证++，–操作是线程安全的！
3.2.2 AtomicInteger使用
  • 这四个方法很好的展现了前置加加减减，和 后者加加减减的原理

在这里插入图片描述

  • 不加锁检测线程安全不安全
    • 老问题：count给两个线程，各自加50000次
public static void main(String[] args) throws InterruptedException {
    AtomicInteger atomicInteger = new AtomicInteger(0);
    //只要引用指向不改变，就可以被lambda表达式捕获~
    Thread thread1 = new Thread(() -> {
        for (int i = 0; i < 50000; i++) {
            atomicInteger.getAndIncrement();
        }
    });
    Thread thread2 = new Thread(() -> {
        for (int i = 0; i < 50000; i++) {
            atomicInteger.getAndIncrement();
        }
    });
    thread1.start();
    thread2.start();
    thread1.join();
    thread2.join();
    System.out.println(atomicInteger.get());//获取对应值~
    //不过这个原子类的打印方法，就是打印其对应的值
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 结果表示线程安全：

在这里插入图片描述

  • 源码看不懂_(¦3」∠)_

  • 看伪代码~

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

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • Java没法表示寄存器里的值，而C里面有个register，建议编译器把变量优化到寄存器中
  • 但是这也只是建议，大部分情况，你的优化是不如编译器自己去优化的
  • 这个过程不涉及阻塞等待，比之前加锁的方案，快很多~

解析：

在这里插入图片描述

  • 线程安全分析：

在这里插入图片描述

3.3 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;
   }
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • owner记录了锁的拥有者~
    • 为 null的时候，说明锁未被任何线程争夺到~
    • 此时，是可以抢夺锁的

在这里插入图片描述

  • 好处：一旦锁释放，就可以立即获得锁
  • 坏处：忙等，很耗cpu资源

乐观锁—锁冲突概率小的，适用自旋锁~

3.3.1 aba问题

我们在CAS操作的原理中看出compare操作起到的作用

  • 但是会有这么一种情况，就是一个value值，从a —> b —> a
    • 不是没变过，而是变回来了~
    • 而CAS只能判断值是否变化，但是无法确定这个值中间是否发生过变化~
  • 此时，我们有一定概率会出问题。
    • 大部分情况下，都没事！！！
    • 极小概率下会出bug
3.3.2 解决aba问题缺陷
  • 我们只需要，让数据只能单方向变化，那么问题就迎刃而解了~
    • 就是说，让数据一直递增 / 递减
    • 这样就不会又这两种情况：
      • 即解决反复横跳的问题

在这里插入图片描述

问题：我们肯定不能强制这个数据只能增只能减啊！！！

  • 但是我们可以添加一个成员属性，版本号

  • 而这个成员是只能增 / 只能减的

  • 这样，每次CAS操作，对比的就不是数据本身，而是对比版本号~

    • 版本号于每次CAS返回true时应自增 / 自减

伪代码：

class V {
    int number = 100;
    int version = 1;
}

  • 1
  • 2
  • 3
  • 4
if(CAS(version, old, old + 1)) {
    number++;//键值别忘了变~
}

  • 1
  • 2
  • 3

以版本号为基准，而不是以变量数值为基准！！！

4. Synchronized原理

对于synchronized

  1. 既是乐观锁，也是悲观锁
  2. 既是轻量级锁，也是重量级锁
  3. 轻量级锁基于自旋实现，重量级锁基于挂起等待实现
  4. 是互斥锁，不是读写锁
  5. 是可重入锁
  6. 是非公平锁

以后遇到其他锁，可以依照这些特定对号入座~

  • 本章节并不涉及，实现一把锁的操作
    • 在Java标准库里有，AQS实现锁的框架，感兴趣可以去研究研究

4.1 锁升级

  • 锁升级是synchronized关键字的重要策略

在这里插入图片描述

  • 这个升级策略，可以尽可能省的去干活~

而偏向锁是这里唯一没讲到过的。

  • 偏向锁， 是一个线程抢到锁之后，并没有处于一种锁的状态，而是拿着锁不锁~
  • 即，此时没人跟我竞争，我其实可以一直不加锁，即使我抢到锁，但是非必要不加锁~
    • 而一旦有人参与锁竞争，我就立马加锁！
  • 这就相当于 “搞暧昧”

主要还是为了尽可能优化速率

  • 偏向锁就相当于给对象处于 “偏向于锁的状态”，就是做了个标记，而做标记这个操作很轻快~
  • 这样做既保证了效率，又保证了线程安全

对于自旋锁变为挂起等待锁

  1. 我们主流的系统windows和linux调度开销很大。系统不承诺能在某时间段内完成调度。
    • 所以，极端情况下，调度的开销会极端的大
  2. 还存在另外一种，实时操作系统，例如vxworks
    • 就能够以更低的成本完成任务调度，但是这种系统牺牲了主流操作系统的很多功能！ ！
      • 对于一些任务，要求时间精度高且不需要其他功能
      • 我们就可以用这种操作系统去搞！
    • 此时自旋锁的CPU消耗比前者低~

主流的JVM的实现，只能锁升级，不能锁降级~

  • 不是实现不了
  • 而是收益与代价相比，大佬们可能觉得不划算~

4.2 锁消除

非必要不加锁，但是我们之前的是在代码运行层面的不加锁

  • 而锁消除机制则是在编译时期就做出了优化~

编译时，智能检测当前代码，是否是多线程或者是是否有必要加锁

  • 如果没有必要，但是你把锁给写了，就会在编译时期把锁消除掉~

synchronized不应该被滥用的，开销大~

  • 比如说，StringBuilder和StringBuffer这两个类
    • 前者线程不安全，后者线程安全
    • 如果每次无脑都用StringBuffer的话，开销大
      • 本质上就是synchronized修饰了StringBuffer的所有关键的方法（下一篇文章会讲）
  • 而synchronized的锁消除机制会很好的将这种滥用或者不经意滥用的情况消除掉~
  • 而本质不影响最终效果

在这里插入图片描述

4.3 锁粗化

粒度： 即细化的程度。被封锁的对象的粒度。例如数据项、记录、文件或整个数据库，锁粒度越小事务的并行度越高。

  • 粒度就相当于代码的规模大小，代码越多粒度越粗，代码越少粒度越细
    • 一般我们写代码是希望粒度细点好，减少串行，增加并行并发
    • 充分利用CPU资源

但是，如果在一个需要频繁加锁解锁的场景下，粒度细会导致开销更大！

  • 这样，编译器就会优化你的代码，粗化代码粒度，减少加锁解锁

    • 类比一下，如果你给你老板打电话汇报工作1、2、3，你打通了，他也被你“锁”住了，而你却没一次性说完，分三次汇报。这样老板就会看你不爽~

  • 这样也可以保证一个任务的完整性，毕竟线程调度随机，一个任务可能会因为部分环节延后了。

一样的，不会影响最终结果~

在这里插入图片描述

文章到此结束！谢谢观看可以叫我 小马，我可能写的不好或者有错误，但是一起加油鸭

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小丑西瓜9/article/detail/647185
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。