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

1. 锁策略

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

1.1 乐观锁 vs 悲观锁

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

乐观锁 ==> 预测接下来冲突概率小

工作量更少，效率大

悲观锁 ==> 预测接下来冲突概率大

工作量更多，效率小

但是并不绝对。

这里的工作量就是锁操作的内部一些操作

了解概念即可~

1.2 轻量级锁 vs 重量级锁

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

轻量级锁 ==> 加锁解锁更快更高效

重量级锁 ==> 加锁解锁更慢更低效

轻量级锁很可能是乐观锁

重量级锁很可能是悲观锁

但是不绝对~

1.3 自旋锁 & 挂起等待锁

这跟轻重锁有密切联系

自旋锁 ==> 轻量级锁的典型实现

挂起等待锁 ==> 重量级锁的典型实现

对于自旋锁：

对于遇到锁冲突，并没有选择等待，而是没闲着，反复确认是否锁被释放

这样子做虽然精度高，但是消耗CPU资源大，即忙等

重量级锁这样会，导致其他任务受限，得不偿失~

对于挂起等待锁

对于遇到锁冲突，直接中断任务，等待锁释放

这样子做虽然精度不高，但是可以让CPU去干其他的任务

轻量级锁这样做，可能会导致轻量级锁的任务不能满足更精的要求

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

轻量

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

重量

1.4 synchronized属于哪种锁？

synchronized即是乐观锁又是悲观锁，即是轻量级锁，又是重量级锁

轻量级部分基于自旋锁实现

重量级部分基于挂起等待锁实现

感觉情况，变化，自适应

如果锁冲突不激烈，以轻量级锁/乐观锁去适应

如果锁冲突很激烈，以重量级锁/悲观锁去适应

尽可能节省地，保证线程安全~

没错，JVM就是这么牛

1.5 互斥锁 vs 读写锁

synchronized是互斥锁，就只是单纯加锁，没有更细化的部分~

加锁

释放锁

对于读写锁：

对读加锁

对写加锁

释放锁

读写锁约定：

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

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

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

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

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

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

ReentrantReadWriteLock的源码发现,

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

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

1.6 公平锁 vs 非公平锁

规定：遵守先来后到称为公平锁，不遵守先来后到称为非公平锁

可能我们直观的想法是，抢到锁的概率是否一样来觉得公平不公平~

而这个规定就是发明这个概念的大佬定下来的~

就是，一个锁被一个线程抢了，而其他线程都在等待，但是等的时间不一样

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

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

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

即线程 3 2 4顺序

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

2. 死锁

2.1 可重入锁 vs 不可重入锁

对于一个线程，针对同一把锁，连续加锁两次

出现死锁了，就是不可重入锁

不出现死锁，就是可重入锁

对于不可重入锁：

同一把锁：同一锁对象

举个栗子：

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

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

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

这是一个被锁住的方法

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

在同一个类之中的另一个锁方法，调用A方法

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

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

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

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

即会判断自己是否是锁的拥有者

没错，JVM就是这么牛

2.2 两个线程两把锁

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

当然，若线程1或者线程2进入第二层锁，那么另一个线程也不会进入第一层锁，这样也不会出现死锁

但是，线程调度无序性呀，出现同时进入第一层锁是很有可能的！

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

2.3 N个线程，M把锁

线程越多，锁越多，更容易出现死锁情况了~

2.3.1 哲学家就餐问题

那么就会出现如下情况：

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

因为，他们在等待别人放下筷子~

而这里的别人也在等他们自己放下筷子~

由此可见，线程越多，锁越多，更容易出现死锁情况了~

2.3.2 死锁的基本特点，四个必要条件

互斥使用

不可抢占，一个锁只能由锁的拥有者自行释放，不能强行占用~

请求和保持，（去抢别的锁，但是却没有释放原本的锁）

循环等待，（逻辑形成循环）

四个条件缺一不可！

1和2是锁的基本特点

而3和4，代码的特点

就是哲学家就餐问题的根本原因！

2.3.3 死锁的处理

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

有很多方法可以处理

而在开发中，最实用简单的就是：【按顺序加锁】

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

例如，两个线程两把锁：

交叉代表了，

可能会互相影响！

锁内部要抢的锁，可能会被别人抢走，进而导致我无法释放锁，别人无法获得我的锁

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

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

给锁编号，方便排序管理~

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

都按照1234

不会导致交叉，即不会死锁

若其中有线程不满足！

就会导致交叉，即有可能会死锁！

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

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

【哲学家就餐问题】解决：

首先，对筷子进行编号：

约定，哲学家只能先拿编号小的筷子，才能拿编号大的筷子

【外提一嘴，对于这种实际问题，我觉得哲学家太固执了，估计也不会遵循】

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

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

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

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

并且，之后的过程，也不会产生“死锁现象”

这样，原本死锁的问题被巧妙的破解了~

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

3. CAS操作

3.1 CAS介绍

CAS ==> Compare-And-Swap

即，比较和交换

作用就是：

boolean CAS(M, A, B)

M为内存地址，A和B为寄存器的值

发现M对应的值与A相等，则交换B和内存M对应的值，返回true

B可能也来自另一个内存，不好说~

发现M对应的值与A不同，啥也不做，则返回false

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

下面为CAS的伪代码~

boolean CAS(M, A, B) {
    if (*M == A) {
        *M = B;
        return true;
    }
    return false;
}

重点：

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());//获取对应值~
    //不过这个原子类的打印方法，就是打印其对应的值
}

结果表示线程安全：

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

看伪代码~

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

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

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

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

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

4. Synchronized原理

对于synchronized

既是乐观锁，也是悲观锁

既是轻量级锁，也是重量级锁

轻量级锁基于自旋实现，重量级锁基于挂起等待实现

是互斥锁，不是读写锁

是可重入锁

是非公平锁

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

本章节并不涉及，实现一把锁的操作

在Java标准库里有，AQS实现锁的框架，感兴趣可以去研究研究

4.1 锁升级

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

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

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

偏向锁，是一个线程抢到锁之后，并没有处于一种锁的状态，而是拿着锁不锁~

即，此时没人跟我竞争，我其实可以一直不加锁，即使我抢到锁，但是非必要不加锁~

而一旦有人参与锁竞争，我就立马加锁！

这就相当于 “搞暧昧”

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

偏向锁就相当于给对象处于 “偏向于锁的状态”，就是做了个标记，而做标记这个操作很轻快~

这样做既保证了效率，又保证了线程安全

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

我们主流的系统windows和linux调度开销很大。系统不承诺能在某时间段内完成调度。

所以，极端情况下，调度的开销会极端的大

还存在另外一种，实时操作系统，例如vxworks

就能够以更低的成本完成任务调度，但是这种系统牺牲了主流操作系统的很多功能！！

对于一些任务，要求时间精度高且不需要其他功能

我们就可以用这种操作系统去搞！

此时自旋锁的CPU消耗比前者低~

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

不是实现不了

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

4.2 锁消除

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

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

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

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

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

比如说，StringBuilder和StringBuffer这两个类

前者线程不安全，后者线程安全

如果每次无脑都用StringBuffer的话，开销大

本质上就是synchronized修饰了StringBuffer的所有关键的方法（下一篇文章会讲）

而synchronized的锁消除机制会很好的将这种滥用或者不经意滥用的情况消除掉~

而本质不影响最终效果

4.3 锁粗化

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

粒度就相当于代码的规模大小，代码越多粒度越粗，代码越少粒度越细

一般我们写代码是希望粒度细点好，减少串行，增加并行并发

充分利用CPU资源

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

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

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

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

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

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

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

1. 锁策略

1.1 乐观锁 vs 悲观锁

1.2 轻量级锁 vs 重量级锁

1.3 自旋锁 & 挂起等待锁

1.4 synchronized属于哪种锁？

1.5 互斥锁 vs 读写锁

1.6 公平锁 vs 非公平锁

2. 死锁

2.1 可重入锁 vs 不可重入锁

2.2 两个线程两把锁

2.3 N个线程，M把锁

2.3.1 哲学家就餐问题

2.3.2 死锁的基本特点，四个必要条件

2.3.3 死锁的处理

3. CAS操作

3.1 CAS介绍

3.2 CAS操作实现原子类

3.2.1 AtomicInteger类

3.2.2 AtomicInteger使用

3.3 CAS操作实现自旋锁

3.3.1 aba问题

3.3.2 解决aba问题缺陷

4. Synchronized原理

4.1 锁升级

4.2 锁消除

4.3 锁粗化

热门文章

最新文章

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

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

1. 锁策略

1.1 乐观锁 vs 悲观锁

1.2 轻量级锁 vs 重量级锁

1.3 自旋锁 & 挂起等待锁

1.4 synchronized属于哪种锁？

1.5 互斥锁 vs 读写锁

1.6 公平锁 vs 非公平锁

2. 死锁

2.1 可重入锁 vs 不可重入锁

2.2 两个线程两把锁

2.3 N个线程，M把锁

2.3.1 哲学家就餐问题

2.3.2 死锁的基本特点，四个必要条件

2.3.3 死锁的处理

3. CAS操作

3.1 CAS介绍

3.2 CAS操作实现原子类

3.2.1 AtomicInteger类

3.2.2 AtomicInteger使用

3.3 CAS操作实现自旋锁

3.3.1 aba问题

3.3.2 解决aba问题缺陷

4. Synchronized原理

4.1 锁升级

4.2 锁消除

4.3 锁粗化

热门文章

最新文章

相关电子书