超强图文|并发编程【等待/通知机制】就是这个feel~

简介: 超强图文|并发编程【等待/通知机制】就是这个feel~

微信图片_20220510165814.png


  • 你有一个思想,我有一个思想,我们交换后,一个人就有两个思想
  • If you can NOT explain it simply, you do NOT understand it well enough


微信图片_20220510165834.png


并发编程为什么会有等待通知机制


上一篇文章说明了 Java并发死锁解决思路 , 解决死锁的思路之一就是 破坏请求和保持条件, 所有柜员都要通过唯一的账本管理员一次性拿到所有转账业务需要的账本,就像下面这样:


微信图片_20220510165851.png


没有等待/通知机制之前,所有柜员都通过死循环的方式不断向账本管理员申请所有账本,程序的体现就是这样:


while(!accountBookManager.getAllRequiredAccountBook(this, target));


假如账本管理员是年轻小伙,腿脚利落(即执行 getAllRequiredAccountBook方法耗时短),并且多个柜员转账的业务冲突量不大,这个方案简单粗暴且有效,柜员只需要尝试几次就可以成功(即通过少量的循环可以实现)


过了好多年,年轻的账本管理员变成了年迈的老人,行动迟缓(即执行 getAllRequiredAccountBook 耗时长),同时,多个柜员转账的业务冲突量也变大,之前几十次循环能做到的,现在可能就要申请成千上百,甚至上万次才能完成一次转账


微信图片_20220510165920.png


人工无限申请浪费口舌, 程序无限申请浪费CPU。聪明的人就想到了 等待/通知 机制


等待/通知机制


无限循环实在太浪费CPU,而理想情况应该是这样:


  • 柜员A如果拿不到所有账本,就傲娇的不再继续问了(线程阻塞自己 wait)


  • 柜员B归还了柜员A需要的账本之后就主动通知柜员A账本可用(通知等待的线程 notify/notifyAll)


做到这样,就能避免循环等待消耗CPU的问题了


现实中有太多场景都在应用等待/通知机制。欢迎观临红浪漫,比如去XX办证,去医院就医/体检。


下面请自行脑补一下去医院就医或体检的画面, 整体流程类似这样:


序号 就医 程序解释(自己的视角)
1 挂号成功,到诊室门口排号候诊 排号的患者(线程)尝试获取【互斥锁】
2 大夫叫到自己,进入诊室就诊 自己【获取到互斥锁】
3 大夫简单询问,要求做检查(患者缺乏报告不能诊断病因) 进行【条件判断】,线程要求的条件【没满足】
4 自己出去做检查 线程【主动释放】持有的互斥锁
5 大夫叫下一位患者 另一位患者(线程)获取到互斥锁
6 自己拿到检测报告 线程【曾经】要求的条件得到满足(实则【被通知】)
7 再次在诊室门口排号候诊 再次尝试获取互斥锁
8 ... ...


在【程序解释】一列,我将关键字(排队、锁、等待、释放....)已经用 【】 框了起来。Java 语言中,其内置的关键字 synchronized 和 方法wait(),notify()/notifyAll() 就能实现上面提到的等待/通知机制,我们将这几个关键字实现流程现形象化的表示一下:


微信图片_20220510165946.png


这可不是一个简单的图,下面还要围绕这个图做很多文章,不过这里我必须要插播几个面试基础知识点了:


  1. 一个锁对应一个【入口等待队列】,不同锁的入口等待队列没任何关系,说白了他们就不存在竞争关系。你想呀,不同患者进入眼科和耳鼻喉科看大夫一点冲突都没有


  1. wait(), notify()/notifyAll() 要在 synchronized 内部被使用,并且,如果锁的对象是this,就要 this.wait(),this.notify()/this.notifyAll() , 否则JVM就会抛出 java.lang.IllegalMonitorStateException 的。你想呀,等待/通知机制就是从【竞争】环境逐渐衍生出来的策略,不在锁竞争内部使用或等待/通知错了对象, 自然是不符合常理的


微信图片_20220510170007.png


有了上面知识的铺垫,要想将无限循环策略改为等待通知策略,你还需要问自己四个问题:


灵魂 4 问


微信图片_20220510170030.png


我们拿钱庄账本管理员的例子依依做以上回答:


微信图片_20220510170047.png


我们优化钱庄转账的程序:


public class AccountBookManager {
    List<Object> accounts = new ArrayList<>(2);
    synchronized boolean getAllRequiredAccountBook( Object from, Object to){
        if(accounts.contains(from) || accounts.contains(to)){
            try{
        this.wait();
      }catch(Exception e){
      }
        } else{
            accounts.add(from);
            accounts.add(to);
            return true;
        }
    }
    // 归还资源
    synchronized void releaseObtainedAccountBook(Object from, Object to){
        accounts.remove(from);
        accounts.remove(to);
    notify();
    }
}


就这样【看】 【似】 【完】 【美】的解决了,其实上面的程序有两个大坑:


微信图片_20220510170119.gif


坑一


在上面 this.wait() 处,使用了 if 条件判断,会出现天大的麻烦,来看下图(从下往上看):


微信图片_20220510170138.png


notify 唤醒的那一刻,线程【曾经/曾经/曾经】要求的条件得到了满足,从这一刻开始,到去条件等队列中唤醒线程,再到再次尝试获取锁是有时间差的,当再次获取到锁时,线程曾经要求的条件是不一定满足,所以需要重新进行条件判断,所以需要将 if 判断改成 while 判断


synchronized boolean getAllRequiredAccountBook( Object from, Object to){
        while(accounts.contains(from) || accounts.contains(to)){
            try{
        this.wait();
      }catch(Exception e){
      }
        } else{
            accounts.add(from);
            accounts.add(to);
            return true;
        }
}


一个线程可以从挂起状态变为可运行状态(也就是被唤醒),即使线程没有被其他线程调用 notify()/notifyAll() 方法进行通知,或被中断,或者等待超时,这就是所谓的【 虚假唤醒】。虽然虚假唤醒很少发生,但要防患于未然, 做法就是不停的去测试该线程被唤醒条件是否满足

——摘自《Java并发编程之美》



有同学可能还会产生疑问,为什么while就可以?

因为被唤醒的线程再次获取到锁之后是从原来的 wait 之后开始执行的,wait在循环里面,所以会再次进入循环条件重新进行条件判断。


如果不理解这个道理就记住一句话:


从哪里跌倒就从哪里爬起来;在哪里wait,就从wait那里继续向后执行


所以,这也就成了使用wait()的标准范式


微信图片_20220510170219.png


至于坑二,是线程归还所使用的账户之后使用 notify 而不是 notifyAll 进行通知,由于坑很大,需要一些知识铺垫来说明


为什么说尽量使用 notifyAll


notify() 和 notifyAll() 到底啥区别?


notify() 函数


随机唤醒一个:一个线程调用共享对象的 notify() 方法,会唤醒 一个在该共享变量上调用 wait() 方法后被挂起的线程,一个共享变量上可能有多个线程在等待,具体唤醒那一个,是 随机的


notifyAll() 函数


唤醒所有: 与notify() 不同,notifyAll() 会唤醒在该共享变量上由于调用wait() 方法而被挂起的 所有线程


看个非常简单的程序例子吧


示例程序一


@Slf4j
public class NotifyTest {
    private static volatile Object resourceA = new Object();
    public static void main(String[] args) throws InterruptedException {
        Thread threadA = new Thread(() -> {
                synchronized (resourceA){
                    log.info("threadA get resourceA lock");
                    try{
                        log.info("threadA begins to wait");
                        resourceA.wait();
                        log.info("threadA ends wait");
                    }catch (InterruptedException e){
                        log.error(e.getMessage());
                    }
                }
        });
        Thread threadB = new Thread(() -> {
            synchronized (resourceA){
                log.info("threadB get resourceA lock");
                try{
                    log.info("threadB begins to wait");
                    resourceA.wait();
                    log.info("threadB ends wait");
                }catch (InterruptedException e){
                    log.error(e.getMessage());
                }
            }
        });
        Thread threadC = new Thread(() -> {
            synchronized (resourceA){
                log.info("threadC begin to notify");
                resourceA.notify();
            }
        });
        threadA.start();
        threadB.start();
        Thread.sleep(1000);
        threadC.start();
        threadA.join();
        threadB.join();
        threadC.join();
        log.info("main thread over now");
    }
}


来看运行结果


微信图片_20220510170313.png


程序中我们使用notify()随机通知resourceA的等待队列的一个线程,threadA被唤醒,threadB却没有打印出 threadB ends wait 这句话,遗憾的死掉了

将 notify() 换成 notifyAll() 的结果想必你已经知道了


微信图片_20220510170334.png


使用 notifyAll() 确实不会遗落等待队列中的线程,但也产生了比较强烈的竞争,如果notify() 设计的本身就是 bug,那么这个函数应该早就从 JDK 中移除了,它随机通知一个线程的形式必定是有用武之地的


什么时候可以使用 notify()


微信图片_20220510170411.png


notify() 的典型的应用就是线程池(按照上面的三个条件你自问自答验证一下是这样吗?)


这里我们拿一个 JUC 下的类来看看 notify() 的用处


Tips:


  • notify() 等同于 signal()
  • wait() 等同于 await()


在IDE中,打开 ArrayBlockingQueue.java


微信图片_20220510170443.png


所有的入队 public 方法offer()/put() 内部都调用了 private 的 enqueue() 方法

所有的出队 public 方法poll()/take() 内部都调用了 private 的 dequeue() 方法

将这个模型进行精简就是下面这个样子:


public class SimpleBlockingQueue<T> {
    final Lock lock = new ReentrantLock();
    // 条件变量:队列不满
    final Condition notFull = lock.newCondition();
    // 条件变量:队列不空
    final Condition notEmpty = lock.newCondition();
    // 入队
    void enq(T x) {
        lock.lock();
        try {
            while (队列已满){
                // 等待队列不满
                notFull.await();
            }
            // 省略入队操作...
            //入队后,通知可出队
            notEmpty.signal();
        }finally {
            lock.unlock();
        }
    }
    // 出队
    void deq(){
        lock.lock();
        try {
            while (队列已空){
                // 等待队列不空
                notEmpty.await();
            }
            // 省略出队操作...
            //出队后,通知可入队
            notFull.signal();
        }finally {
            lock.unlock();
        }
    }
}


如果满足上面这三个条件,notify() 的使用就恰到好处;我们用使用 notify()的条件进行验证


微信图片_20220510170519.png


有的同学看到这里可能会稍稍有一些疑惑,await()/signal()wait()/notify() 组合的玩法看着不太一样呢,你疑惑的没有错

因为 Java 内置的监视器锁模型是 MESA 模型的精简版


MESA模型


MESA 监视器模型中说,每一个条件变量都对应一个条件等待队列


微信图片_20220510170540.png


对应到上面程序:


  • 队列已满是前提条件,条件变量A就是notFull,也就是notFull.await; notFull.signal


  • 队列已空是前提条件,条件变量B就是notEmpty,也就是notEmpty.await; notEmpty.signal/sign


即便notFull.signalAll, 也和await在notEmpty 条件变量队列的线程没半毛钱关系


而Java内置监视器模型就只会有一个【隐形的】条件变量


  • 如果是synchronized修饰的普通方法,条件变量就是 this


  • 如果是synchronized修饰的静态方法,条件变量就是类


  • 如果是synchronized块,条件变量就是块中的内容了


说完了这些,你有没有恍然大悟的感觉呢


微信图片_20220510170609.png


总结


如果业务冲突不大,循环等待是一种简单粗暴且有效的方式;但是当业务冲突大之后,通知/等待机制是必不可少的使用策略


通过这篇文章,相信你已经可以通过灵魂4问,知道如何将循环等待改善成通知/等待模型了;另外也知道如何正确的使用通知/等待机制了


灵魂追问


  1. 钱庄转账的业务,条件都是判断账户是否被支配,都是执行相同的转账业务,为什么就不可以用notify() 而只能用notifyAll() 呢


  1. ResourceA的例子,为什么使用notify通知,程序没有打印出 main thread over now, 而使用notifyAll() 却打印出来了呢?


目录
打赏
0
0
0
0
1
分享
相关文章
线程的中断(interrupt)机制
线程的中断(interrupt)机制
214 1
C++实现单例模式-多种方式比较
单例模式,面试中经常被问到,但是很多人只会最简单的单例模型,可能连多线程都没考虑到,本文章从最简单的单例,到认为是最佳的单例模式实现方式,单例模式没有什么知识点,直接上源码
190 0
RocketMQ事务消息, 图文、源码学习探究~
介绍 RocketMQ是阿里巴巴开源的分布式消息中间件,它是一个高性能、低延迟、可靠的消息队列系统,用于在分布式系统中进行异步通信。 从4.3.0版本开始正式支持分布式事务消息~ RocketMq事务消息支持最终一致性:在普通消息基础上,支持二阶段的提交能力。将二阶段提交和本地事务绑定,实现全局提交结果的一致性。 原理、流程 本质上RocketMq的事务能力是基于二阶段提交来实现的 在消息发送上,将二阶段提交与本地事务绑定 本地事务执行成功,则事务消息成功,可以交由Consumer消费 本地事务执行失败,则事务消息失败,Consumer无法消费 但是,RocketMq只能保证本地事务
阿里云CDN:构建全球化智能加速网络的数字高速公路
阿里云CDN构建全球化智能加速网络,拥有2800多个边缘节点覆盖67个国家,实现毫秒级网络延迟。其三级节点拓扑结构与智能路由系统,结合流量预测模型,确保高命中率。全栈式加速技术包括QUIC协议优化和Brotli压缩算法,保障安全与性能。五层防御机制有效抵御攻击,行业解决方案涵盖视频、物联网及游戏等领域,支持新兴AR/VR与元宇宙需求,持续推动数字内容分发技术边界。
141 13
深入探索 Python 爬虫:高级技术与实战应用
本文介绍了Python爬虫的高级技术,涵盖并发处理、反爬虫策略(如验证码识别与模拟登录)及数据存储与处理方法。通过asyncio库实现异步爬虫,提升效率;利用tesseract和requests库应对反爬措施;借助SQLAlchemy和pandas进行数据存储与分析。实战部分展示了如何爬取电商网站的商品信息及新闻网站的文章内容。提醒读者在实际应用中需遵守法律法规。
386 66
大数据学习
【10月更文挑战第15天】
242 1
Java线程池提交任务流程底层源码与源码解析
【11月更文挑战第30天】嘿,各位技术爱好者们,今天咱们来聊聊Java线程池提交任务的底层源码与源码解析。作为一个资深的Java开发者,我相信你一定对线程池并不陌生。线程池作为并发编程中的一大利器,其重要性不言而喻。今天,我将以对话的方式,带你一步步深入线程池的奥秘,从概述到功能点,再到背景和业务点,最后到底层原理和示例,让你对线程池有一个全新的认识。
157 12
|
7月前
|
多线程编程核心:上下文切换深度解析
在现代计算机系统中,多线程编程已成为提高程序性能和响应速度的关键技术。然而,多线程编程中一个不可避免的概念就是上下文切换(Context Switching)。本文将深入探讨上下文切换的概念、原因、影响以及优化策略,帮助你在工作和学习中深入理解这一技术干货。
142 10
tcp 可以建立多个连接吗?
【10月更文挑战第25天】TCP(传输控制协议)是一种面向连接的、可靠的传输层协议,它在网络通信中起着重要的作用。在 TCP 中,可以建立多个连接,这种特性被称为TCP 连接复用。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问