案例发生死锁的分析

案例发生死锁的分析

根据我自己的测试:

1.当Producer线程连续两次比Consumer线程先获得对象queue的锁(也就cpu是连续两次运行queue.set(),此时flag为true,Producer线程开始等待),并且之后Consumer线程连续两次获得对象queue的锁(也就是cpu连续两次运行queue.get(),此时flag为false,Consumer线程开始等待),这样就死锁了。

2.同理,Consumer线程连续两次比Producer线程先获得锁,之后Producer线程再连续两次获得锁,也会导致死锁。

感觉概率还是比较低的,毕竟两个线程都要连续两次获得锁。我的分析对吗,会有两种情况死锁是吧?实际测试只出现了一种情况的死锁,不知道是不是测试太少了。

正在回答

登陆购买课程后可参与讨论,去登陆

1回答

同学您好,当第二次重复执行Producer线程或者Consumer线程时,由于第一次执行时,已经对标记变量进行过修改,所以第二次并不会在此处进行阻塞,而是直接释放CPU的占有权。接下来也是如此,无论多少次重复该线程,都会立即释放CPU的占有权,也就不会形成死锁。

祝同学学习愉快~

  • weixin_慕村4552609 提问者 #1
    get和set方法不是固定交替的,我知道,所以当get或者set连续执行两次,就必然会死锁
    2021-12-18 12:14:51
  • 同学您好,非常抱歉,之前是老师对同学上述的描述理解有些许偏差,已经对答案进行过修改,请同学查看。

    祝同学学习愉快~

    2021-12-18 14:00:58
  • 老师,对于连续两次get消费者线程是阻塞我的理解是:

    虽然存在同一个线程获取两次CPU的使用权,但是在执行方法之前不是有判断嘛,当消费者线程第二次获取CPU的使用权的时候会阻塞从而主动释放CPU使用权,生产者线程就会得以执行,后面只要执行一次生产者线程的set方法就会唤醒消费者线程啊,因为里面不是有

    notifyAll

    方法嘛,就算是再执行一次set方法,生产者也是阻塞也没事啊,因为第一次已经唤醒消费者了从而消费者线程得以执行,所以题主描述的那种情况是真实存在的吗?

    2022-04-10 09:40:16
问题已解决,确定采纳
还有疑问,暂不采纳

恭喜解决一个难题,获得1积分~

来为老师/同学的回答评分吧

0 星
请稍等 ...
意见反馈 帮助中心 APP下载
官方微信

在线咨询

领取优惠

免费试听

领取大纲

扫描二维码,添加
你的专属老师