啃碎并发(八):深入分析wait&notify原理

前言

=====

上一节讲了Synchronized关键词的原理与优化分析,而配合Synchronized使用的另外两个关键词wait¬ify是本章讲解的重点。最简单的东西,往往包含了最复杂的实现,因为需要为上层的存在提供一个稳定的基础, Object作为Java中所有对象的基类,其存在的价值不言而喻,其中wait&notify方法的实现多线程协作提供了保证

1 源码

今天我们要学习或者说分析的是 Object 类中的 wait&notify 这两个方法,其实说是两个方法,这两个方法包括他们的重载方法一共有 5 个,而 Object 类中一共才 12 个方法,可见这 2 个方法的重要性。我们先看看 JDK 中的代码

啃碎并发(八):深入分析wait&notify原理

就是这五个方法。 其中有 3 个方法是 native 的,也就是由虚拟机本地的 c 代码执行的 。有 2 个 wait 重载方法最终还是调用了 wait(long) 方法。

1.wait方法:wait是要释放对象,进入等待池。 既然是释放对象锁,那么肯定是先要获得锁 。所以wait必须要写在synchronized代码块中,否则会报异常。

2.notify方法:也需要写在synchronized代码块中,调用对象的这两个方法也需要先获得该对象的锁。 notify,notifyAll,唤醒等待该对象同步锁的线程,并放入该对象的锁池中。对象的锁池中线程可以去竞争得到对象锁,然后开始执行

啃碎并发(八):深入分析wait&notify原理

另外一点比较重要, notify,notifyAll调用时并不会释放对象锁 。比如以下代码:

啃碎并发(八):深入分析wait&notify原理

虽然调用了notifyAll,但是紧接着进入了一个死循环。 导致一直不能出临界区,一直不能释放对象锁 。所以,即使它把所有在等待池中的线程都唤醒放到了对象的锁池中, 但是锁池中的所有线程都不会运行,因为他们始终拿不到锁

===

2 用法

====

简单示例:

啃碎并发(八):深入分析wait&notify原理

执行结果:

啃碎并发(八):深入分析wait&notify原理

前提:必须由同一个lock对象调用wait、notify方法

啃碎并发(八):深入分析wait&notify原理

lock对象、线程A和线程B三者是一种什么关系?根据上面的结论,可以想象一个场景:

啃碎并发(八):深入分析wait&notify原理

3 相关疑问

3.1 为何wait&notify必须要加synchronized锁

从实现上来说,这个锁至关重要, 正因为这把锁,才能让整个wait/notify玩转起来 ,当然我觉得其实通过其他的方式也可以实现类似的机制, 不过hotspot至少是完全依赖这把锁来实现wait/notify的

啃碎并发(八):深入分析wait&notify原理

synchronized代码块通过javap生成的字节码中包含  monitorenter 和  monitorexit 指令。如下图所示:

啃碎并发(八):深入分析wait&notify原理

javap生成的字节码

执行 monitorenter 指令可以获取对象的monitor,而  lock.wait() 方法通过调用native方法wait(0)实现,其中接口注释中有这么一句:

啃碎并发(八):深入分析wait&notify原理

表示线程执行 lock.wait() 方法时,必须持有该lock对象的monitor,如果wait方法在synchronized代码中执行,该线程很显然已经持有了monitor。

3.2 为什么wait方法可能抛出InterruptedException异常

这个异常大家应该都知道,当我们调用了某个线程的interrupt方法时,对应的线程会抛出这个异常,wait方法也不希望破坏这种规则, 因此就算当前线程因为wait一直在阻塞,当某个线程希望它起来继续执行的时候,它还是得从阻塞态恢复过来,因此wait方法被唤醒起来的时候会去检测这个状态 ,当有线程interrupt了它的时候,它就会抛出这个异常从阻塞状态恢复过来。

这里有两点要注意:

啃碎并发(八):深入分析wait&notify原理

3.3 notify执行之后立马唤醒线程吗

其实hotspot里真正的实现是退出同步块的时候才会去真正唤醒对应的线程,不过这个也是个默认策略,也可以改的,在notify之后立马唤醒相关线程。

3.4 notifyAll是怎么实现全唤起所有线程

或许大家立马想到这个简单,一个for循环就搞定了,不过在JVM里没实现这么简单, 而是借助了monitorexit ,上面提到了当某个线程从wait状态恢复出来的时候,要先获取锁,然后再退出同步块, 所以notifyAll的实现是调用notify的线程在退出其同步块的时候唤醒起最后一个进入wait状态的线程,然后这个线程退出同步块的时候继续唤醒其倒数第二个进入wait状态的线程 ,依次类推,同样这这是一个策略的问题,JVM里提供了挨个直接唤醒线程的参数,不过都很罕见就不提了。

3.5 wait的线程是否会影响load

这个或许是大家比较关心的话题,因为关乎系统性能问题wait/nofity是通过JVM里的park/unpark机制来实现的,在Linux下这种机制又是通过

pthread_cond_wait/pthread_cond_signal来玩的,因此当线程进入到wait状态的时候其实是会放弃cpu的,也就是说这类线程是不会占用cpu资源

原文 

https://segmentfault.com/a/1190000023179153

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 啃碎并发(八):深入分析wait&notify原理

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址