Inside AbstractQueuedSynchronizer (1)

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类中比较重要的方法有以下几个：

Java代码  

1. public static void park() {  
2.     unsafe.park(false, 0L);  
3. }  
4.   
5. public static void park(Object blocker) {  
6.     Thread t = Thread.currentThread();  
7.     setBlocker(t, blocker);  
8.     unsafe.park(false, 0L);  
9.     setBlocker(t, null);  
10. }  
11.   
12. public static void unpark(Thread thread) {  
13.     if (thread != null)  
14.         unsafe.unpark(thread);  
15. }  

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

Java代码  

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

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

Java代码  

1. LockSupport.unpark(Thread.currentThread());  
2. LockSupport.unpark(Thread.currentThread());  
3. LockSupport.park();  
4. LockSupport.park();  

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