java locksupport_为什么说LockSupport是Java并发的基石？

编者注：当需要阻塞或唤醒一个线程的时候，JVM都会使用LockSupport工具类来完成相应工作。LockSupport定义了一组的公共静态方法，这些方法提供了最基本的线程阻塞和唤醒功能，而LockSupport也被称为构建同步组件的基础工具。

Java并发组件和并发工具类如下：并发组件：线程池、阻塞队列、Future和FutureTask、Lock和Condition。

并发工具：CountDownLatch、CyclicBarrier、Semaphore和Exchanger。

并发组件和并发工具大都是基于AQS来实现的：队列同步器AbstractQueuedSynchronizer(以下简称同步器)，是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，并发包的作者(Doug Lea)期望它能够成为实现大部分同步需求的基础。

而AQS中的控制线程又是通过LockSupport类来实现的，因此可以说，LockSupport是Java并发基础组件中的基础组件。LockSupport定义了一组以park开头的方法用来阻塞当前线程，以及unpark(Thread thread)方法来唤醒一个被阻塞的线程。LockSupport提供的阻塞和唤醒方法如下：

LockSupport工具实现原理

LockSupport常用方法源码如下：

// LockSupportpublic static void park(Object blocker) {

Thread t = Thread.currentThread();

// blocker在什么对象上进行的阻塞操作 setBlocker(t, blocker);

UNSAFE.park(false, 0L);

setBlocker(t, null);

}

public static void parkNanos(Object blocker, long nanos) {

if (nanos > 0) {

Thread t = Thread.currentThread();

setBlocker(t, blocker);

// 超时阻塞 UNSAFE.park(false, nanos);

setBlocker(t, null);

}

}

public static void unpark(Thread thread) {

if (thread != null)

UNSAFE.unpark(thread);

}

使用park和unpark进行线程的阻塞和唤醒操作，park和unpark底层是借助系统层(C语言)方法pthread_mutex和pthread_cond来实现的，通过pthread_cond_wait函数可以对一个线程进行阻塞操作，在这之前，必须先获取pthread_mutex，通过pthread_cond_signal函数对一个线程进行唤醒操作。

pthread_mutex和pthread_cond使用示例如下：

void *r1(void *arg)

{

pthread_mutex_t* mutex = (pthread_mutex_t *)arg;

static int cnt = 10;

while(cnt--)

{

printf("r1: I am wait.\n");

pthread_mutex_lock(mutex);

pthread_cond_wait(&cond, mutex); /* mutex参数用来保护条件变量的互斥锁，调用pthread_cond_wait前mutex必须加锁 */

pthread_mutex_unlock(mutex);

}

return "r1 over";

}

void *r2(void *arg)

{

pthread_mutex_t* mutex = (pthread_mutex_t *)arg;

static int cnt = 10;

while(cnt--)

{

pthread_mutex_lock(mutex);

printf("r2: I am send the cond signal.\n");

pthread_cond_signal(&cond);

pthread_mutex_unlock(mutex);

sleep(1);

}

return "r2 over";

}注意，Linux下使用pthread_cond_signal的时候，会产生“惊群”问题的，但是Java中是不会存在这个“惊群”问题的，那么Java是如何处理的呢？

实际上，Java只会对一个线程调用pthread_cond_signal操作，这样肯定只会唤醒一个线程，也就不存在所谓的惊群问题。Java在语言层面实现了自己的线程管理机制(阻塞、唤醒、排队等)，每个Thread实例都有一个独立的pthread_u和pthread_cond(系统层面的/C语言层面)，在Java语言层面上对单个线程进行独立唤醒操作。(怎么感觉Java中线程有点小可怜呢，只能在Java线程库的指挥下作战，竟然无法直接获取同一个pthread_mutex或者pthread_cond。但是Java这种实现线程机制的实现实在太巧妙了，虽然底层都是使用pthread_mutex和pthread_cond这些方法，但是貌似C/C++还没这么强大易用的线程库哈。)具体LockSuuport.park和LockSuuport.unpark的底层实现可以参考对应JDK源码，下面看一下gdb打印处于LockSuuport.park时的线程状态信息：

由上图可知底层确实是基于pthread_cond函数来实现的。

推荐阅读FutureTask 原理剖析​mp.weixin.qq.com你的ThreadLocal线程安全么​mp.weixin.qq.com深入浅出 Thread.interrupt​mp.weixin.qq.com同学别走，聊聊Lock与Synchronized吧​mp.weixin.qq.comSynchronized的锁升级之路​mp.weixin.qq.com