Inside AbstractQueuedSynchronizer (1)

Inside AbstractQueuedSynchronizer (1)

Inside AbstractQueuedSynchronizer (2)

Inside AbstractQueuedSynchronizer (3)

Inside AbstractQueuedSynchronizer (4)

 

1 Overview

    如果查看ReentrantLock，CountDownLatch，Semaphore，FutureTask，ThreadPoolExecutor的源码，都会发现有个名叫Sync的静态内部类，继承自AbstractQueuedSynchronizer。实际上AbstractQueuedSynchronizer是java.util.concurrent的核心组件之一，它为并发包中的其他synchronizers提供了一组公共的基础设施。

 

2 LockSupport
    在介绍AbstractQueuedSynchronizer之前，首先要介绍一下java.util.concurrent.locks.LockSupport。在LockSupport出现之前，如果要block/unblock某个Thread，除了使用Java语言内置的monitor机制之外，只能通过Thread.suspend()和Thread.resume()。然而Thread.suspend()和Thread.resume()基本上不可用，除了可能导致死锁之外，它们还存在一个无法解决的竞争条件：如果在调用Thread.suspend()之前调用了Thread.resume()，那么该Thread.resume()调用没有任何效果。LockSupport最主要的作用，便是通过一个许可(permit)状态，解决了这个问题。

 

      那么LockSupport和Java语言内置的monitor机制有什么区别呢？它们的语义是不同的。LockSupport是针对特定Thread来进行block/unblock操作的；wait()/notify()/notifyAll()是用来操作特定对象的等待集合的。为了防止知识生锈，在这里简单介绍一下Java语言内置的monitor机制(详见：http://whitesock.iteye.com/blog/162344 )。正如每个Object都有一个锁， 每个Object也有一个等待集合（wait set），它有wait、notify、notifyAll和Thread.interrupt方法来操作。同时拥有锁和等待集合的实体，通常被成为监视器（monitor）。每个Object的等待集合是由JVM维护的。等待集合一直存放着那些因为调用对象的wait方法而被阻塞的线程。由于等待集合和锁之间的交互机制，只有获得目标对象的同步锁时，才可以调用它的wait、notify和notifyAll方法。这种要求通常无法靠编译来检查，如果条件不能满足，那么在运行的时候调用以上方法就会导致其抛出IllegalMonitorStateException。

 

    wait() 方法被调用后，会执行如下操作：

• 如果当前线程已经被中断，那么该方法立刻退出，然后抛出一个InterruptedException异常。否则线程会被阻塞。
• JVM把该线程放入目标对象内部且无法访问的等待集合中。
• 目标对象的同步锁被释放，但是这个线程锁拥有的其他锁依然会被这个线程保留着。当线程重新恢复质执行时，它会重新获得目标对象的同步锁。

    notify()方法被调用后，会执行如下操作：

• 如果存在的话，JVM会从目标对象内部的等待集合中任意移除一个线程T。如果等待集合中的线程数大于1，那么哪个线程被选中完全是随机的。
• T必须重新获得目标对象的同步锁，这必然导致它将会被阻塞到调用Thead.notify()的线程释放该同步锁。如果其他线程在T获得此锁之前就获得它，那么T就要一直被阻塞下去。
• T从执行wait()的那点恢复执行。

    notifyAll()方法被调用后的操作和notify()类似，不同的只是等待集合中所有的线程（同时）都要执行那些操作。然而等待集合中的线程必须要在竞争到目标对象的同步锁之后，才能继续执行。

 

    LockSupport类中比较重要的方法有如下几个：

public static void park() {
    unsafe.park(false, 0L);
}

public static void park(Object blocker) {
    Thread t = Thread.currentThread();
    setBlocker(t, blocker);
    unsafe.park(false, 0L);
    setBlocker(t, null);
}

public static void unpark(Thread thread) {
    if (thread != null)
        unsafe.unpark(thread);
}

    其中park()和park(Object blocker)方法用于block当前线程，unpark(Thread thread)方法用于unblock制定的线程。 跟Thread.suspend()和Thread.resume()不同的是，LockSupport通过许可(permit)机制保证：如果当前线程拥有许可，那么park系列方法会消费掉该许可，并且立即返回（不会被阻塞）。也就是说如下代码在执行的时候，不会被阻塞：

LockSupport.unpark(Thread.currentThread());
LockSupport.park();

    需要注意的是：许可不会被累计。也就是说在park调用之前的多次unpark调用，只会unblock一次park调用。即以下代码会被阻塞：

LockSupport.unpark(Thread.currentThread());
LockSupport.unpark(Thread.currentThread());
LockSupport.park();
LockSupport.park();

    关于park()和park(Object blocker)的区别，Object blocker参数的作用在于允许记录当前线程被阻塞的原因，以便监控分析工具进行分析。官方的文档中也更建议使用park(Object blocker)。此外，跟Object.wait()方法一样，park系列方法也会因为伪唤醒的原因返回。