Object.wait() 和 LockSupport.park()的实现原理

Object.wait()

在进行wait()以前，就表明着须要争夺Synchorized，而Synchronized代码块经过javap生成的字节码中包含monitorenter和monitorexit两个指令。
当在进加锁的时候会执行monitorenter指令，执行该指令能够获取对象的monitor。
同时在执行Lock.wait()的时候也必须持有monitor对象。

LockSupport.park()

操做对象

归根结底，LockSupport调用的Unsafe中的native代码：

public native void unpark(Thread jthread); 
public native void park(boolean isAbsolute, long time);

两个函数声明清楚地说明了操做对象：

park函数是将当前Thread阻塞，而unpark函数则是将另外一个Thread唤醒。

与Object类的wait/notify机制相比，park/unpark有两个优势：

1. 以thread为操做对象更符合阻塞线程的直观定义；
2. 操做更精准，能够准确地唤醒某一个线程（notify随机唤醒一个线程，notifyAll唤醒全部等待的线程），增长了灵活性。

关于许可

在上面的文字中，我使用了阻塞和唤醒，是为了和wait/notify作对比。
其实park/unpark的设计原理核心是“许可”。
park是等待一个许可。
unpark是为某线程提供一个许可。
若是某线程A调用park，那么除非另一个线程调用unpark(A)给A一个许可，不然线程A将阻塞在park操做上。

有一点比较难理解的，是unpark操做能够再park操做以前。
也就是说，先提供许可。当某线程调用park时，已经有许可了，它就消费这个许可，而后能够继续运行。
这实际上是必须的。

考虑最简单的生产者(Producer)消费者(Consumer)模型：

Consumer须要消费一个资源，因而调用park操做等待；

Producer则生产资源，而后调用unpark给予Consumer使用的许可。

很是有可能的一种状况是，Producer先生产，这时候Consumer可能尚未构造好（好比线程还没启动，或者还没切换到该线程）。
那么等Consumer准备好要消费时，显然这时候资源已经生产好了，能够直接用，那么park操做固然能够直接运行下去。
若是没有这个语义，那将很是难以操做。

本文由猿必过 YBG 发布