LockSupport 理论与实践

JavaAPI对LockSupport的解释是：用来创建锁和其他同步类的基本线程阻塞原语。

LockSupport 与Thread.suspend()和Thread.resume()的区别
在LockSupport出现之前，如果要block/unblock某个Thread，除了使用Java语言内置的monitor机制之外，只能通过Thread.suspend()和Thread.resume()。目前这两个方法都被标注为废弃，为什么 Thread.suspend 和 Thread.resume 被废弃了？
来自Oracle的官方文档Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?有如下解释：
Thread.suspend 天生容易引起死锁。如果目标线程挂起时在保护系统关键资源的监视器上持有锁，那么其他线程在目标线程恢复之前都无法访问这个资源。如果要恢复目标线程的线程在调用 resume 之前试图锁定这个监视器，死锁就发生了。这种死锁一般自身表现为“冻结（ frozen ）”进程。
LockSupport使用park和unpark方法进行线程的阻塞和解除阻塞操作，每个使用这个类的线程都将与一个许可关联，如果许可可用，则调用park立即返回；否则可能阻塞。如果许可不可用，则调用unpark使其可用，从而避免了死锁问题。

LockSupport 与 Object Monitor的区别
LockSupport是针对特定线程来进行阻塞和解除阻塞操作的；而Object的wait()/notify()/notifyAll()是用来操作特定对象的等待集合的。有关Java内置monitor的知识可参考：Java Monitor 理论与实践。

LockSupport与伪唤醒问题
跟Object.wait()方法一样，park系列方法也会因为伪唤醒的原因返回。为了防止上述情况发生，park方法的使用需要遵守如下约定：

while (!canProceed()) { ... LockSupport.park(this); }

使用示例
使用LockSupport 构建一个先进先出 (first-in-first-out) 非重入锁类的框架。
这个示例使用原子布尔类型来表示锁定的状态，使用队列来存放阻塞的线程。

class FIFOMutex {
   private final AtomicBoolean locked = new AtomicBoolean(false);
   private final Queue<Thread> waiters
     = new ConcurrentLinkedQueue<Thread>();

   public void lock() {
     boolean wasInterrupted = false;
     Thread current = Thread.currentThread();
     waiters.add(current);

     // Block while not first in queue or cannot acquire lock
     while (waiters.peek() != current ||
            !locked.compareAndSet(false, true)) {
        LockSupport.park(this);
        if (Thread.interrupted()) // ignore interrupts while waiting
          wasInterrupted = true;
     }

     waiters.remove();
     if (wasInterrupted)          // reassert interrupt status on exit
        current.interrupt();
   }

   public void unlock() {
     locked.set(false);
     LockSupport.unpark(waiters.peek());
   }
 }

参考资料
Java1.6 API http://docs.oracle.com/javase/6/docs/api/
Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?
中文版连接 http://alexander-mahone.iteye.com/blog/1841142