LockSupport（park/unpark）

Unsafe.park和Unsafe.unpark的底层实现原理

在Linux系统下，是用的Posix线程库pthread中的mutex（互斥量），condition（条件变量）来实现的。
mutex和condition保护了一个_counter的变量，当park时，这个变量被设置为0，当unpark时，这个变量被设置为1。

concurrent包是基于AQS (AbstractQueuedSynchronizer)框架的，AQS框架借助于两个类：
Unsafe（提供CAS操作）
LockSupport（提供park/unpark操作）
因此，LockSupport非常重要。
park函数是将当前调用Thread阻塞，而unpark函数则是将指定线程Thread唤醒。

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

• 以thread为操作对象更符合阻塞线程的直观定义
• 操作更精准，可以准确地唤醒某一个线程（notify随机唤醒一个线程，notifyAll唤醒所有等待的线程），增加了灵活性。

关于“许可”

• 其实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操作当然可以直接运行下去。如果没有这个语义，那将非常难以操作。
  所以只要我们的 park/unpark 成对出现，无论执行顺序如何，都不会因此造成死锁

• 但是这个“许可”是不能叠加的，“许可”是一次性的。
  比如线程B连续调用了三次unpark函数，当线程A调用park函数就使用掉这个“许可”，如果线程A再次调用park，则进入等待状态。

• park不需要获取某个对象的锁

• 因为中断的时候park不会抛出InterruptedException异常，所以需要在park之后自行判断中断状态，然后做额外的处理。就像 sleep ，notify 唤醒后，jvm 会帮助我们检查一次是否有 interrupt 信号，其原理之前做过解析 https://www.cnblogs.com/niuyourou/p/12392942.html ，将检查 interrupt 信号的逻辑放在阻塞线程的逻辑之后，一旦被唤醒，首先执行检查 interrupt 信号的逻辑，检查完后退出 sleep/wait 方法，程序继续向下执行。而 park / unpark 并没有提供类似的机制，如果需要我们应自己在 park 方法后加入检查 interrupt 信号的逻辑。