【J.U.C】LockSupport

文章首发于：clawhub.club

---

LockSupport是用于创建锁和其他同步类的阻塞原语，通过调用Unsafe函数中的接口实现阻塞和解除阻塞的。

pack

方法	解释
park(Object)	挂起当前线程
parkNanos(Object, long)	指定了一个挂起时间（相对于当前的时间），时间到后自动被唤醒；例如1000纳秒后自动唤醒
parkUntil(Object, long)	指定一个挂起时间（绝对时间），时间到后自动被唤醒；例如2018-02-12 21点整自动被唤醒。
park()	和park(Object)相比少了挂起前为线程设置blocker、被唤醒后清理blocker的操作。
parkNanos(long)	和parkNanos(Object, long)类似，仅少了blocker相关的操作
parkUntil(long)	和parkUntil(Object, long)类似，仅少了blocker相关的操作

park(Object blocker)源码分析：

    /**
     * Disables the current thread for thread scheduling purposes unless the
     * permit is available.
     * 除非有许可证，否则为线程调度目的禁用当前线程。
     *
     * 
If the permit is available then it is consumed and the call returns
     * immediately; otherwise
     * the current thread becomes disabled for thread scheduling
     * purposes and lies dormant until one of three things happens:
     * 如果许可证是可用的，那么它将被使用，调用立即返回;
     * 否则，当前线程将出于线程调度的目的被禁用，并处于休眠状态，直到以下三种情况之一发生:
     *
     * 

     * 
Some other thread invokes {@link #unpark unpark} with the
     * current thread as the target; or
     * 其他一些线程以当前线程为目标调用{@link #unpark unpark}
     *
     * 
Some other thread {@linkplain Thread#interrupt interrupts}
     * the current thread; or
     * 其他线程中断当前线程
     *
     * 
The call spuriously (that is, for no reason) returns.
     * 虚假的调用(也就是说，没有理由)返回。
     * 
     *
     * 
This method does not report which of these caused the
     * method to return. Callers should re-check the conditions which caused
     * the thread to park in the first place. Callers may also determine,
     * for example, the interrupt status of the thread upon return.
     * 此方法不报告是哪些原因导致该方法返回。调用者应该重新检查导致线程首先停车的条件。
     * 例如，调用者还可以在返回时确定线程的中断状态。
     *
     * @param blocker the synchronization object responsible for this
     *                thread parking 负责此操作的同步对象
     * @since 1.6
     */
    public static void park(Object blocker) {
        //获取当前线程
        Thread t = Thread.currentThread();
        //设置线程parkBlocker
        setBlocker(t, blocker);
        //阻塞线程
        UNSAFE.park(false, 0L);
        //清除parkBlocker
        setBlocker(t, null);
    }

park支持blocker对象作为参数。此blocker对象在线程受阻塞时被记录，这样监视工具和诊断工具就可以确定线程受阻塞的原因。

unpark

唤醒调用 park 后阻塞的线程，参数为需要唤醒的线程。
unpark(Thread thread)源码：

  /**
     * Makes available the permit for the given thread, if it
     * was not already available.  If the thread was blocked on
     * {@code park} then it will unblock.  Otherwise, its next call
     * to {@code park} is guaranteed not to block. This operation
     * is not guaranteed to have any effect at all if the given
     * thread has not been started.
     * 使给定线程的许可证可用(如果它还没有可用)。如果线程在{@code park}上被阻塞，那么它将解阻塞。
     * 否则，它对{@code park}的下一次调用将保证不会阻塞。
     * 如果没有启动给定的线程，则不能保证此操作具有任何效果。
     *
     * @param thread the thread to unpark, or {@code null}, in which case
     *               this operation has no effect 取消停靠的线程，或{@code null}，在这种情况下，此操作没有效果
     */
    public static void unpark(Thread thread) {
        //如果线程不为空，则处理，解阻塞
        if (thread != null)
            UNSAFE.unpark(thread);
    }

挂起与阻塞分析

• 对线程来说， LockSupport的park/unpark更符合阻塞和唤醒的语义，他们以“线程”作为方法的参数，语义更清晰，使用起来也更方便。而wait/notify使“线程”的阻塞/唤醒对线程本身来说是被动的，要准确的控制哪个线程、什么时候阻塞/唤醒是很困难的，所以是要么随机唤醒一个线程（notify）要么唤醒所有的（notifyAll）。

• park和unpark方法不会出现Thread.suspend和Thread.resume的死锁问题。这是因为许可的存在，调用park的线程和另一个试图将其unpark的线程之间的将没有竞争关系。此外，如果线程被中断或者超时，则park将返回。

• park方法还可以在其他任何时间“毫无理由”地返回，因此通常必须在重新检查返回条件的循环里调用此方法。从这个意义上说，park 是“忙碌等待”的一种优化，它不会浪费这么多的时间进行自旋，但是必须将它与unpark配对使用才更高效。

使用例子

如图：

LockSuport.png

JDK中主要是JUC中使用，CAS和LockSupport是JUC的基石。disruptor框架也使用了LockSupport。