在进行wait()之前，就代表着需要争夺Synchorized，而Synchronized代码块通过javap生成的字节码中包含monitorenter和monitorexit两个指令。
当在进加锁的时候会执行monitorenter指令，执行该指令可以获取对象的monitor。
同时在执行Lock.wait()的时候也必须持有monitor对象。
归根结底，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有两个优点：
- 以thread为操作对象更符合阻塞线程的直观定义；
- 操作更精准，可以准确地唤醒某一个线程（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操作当然可以直接运行下去。
如果没有这个语义，那将非常难以操作。
