前言

Java SDK并发包通过Lock和Condition两个接口来实现管程，其中Lock用于解决互斥问题，Condition用于解决同步问题。我们需要知道，Java语言本身使用synchronized实现了管程的，那么为什么还在SDK中提供另外一种实现呢？欲知为何请看下文。

下面将先阐述再造管程的理由，然后详细介绍Lock和Condition，最后再看实现同步机制时是选择synchronized还是SDK中的管程。

再造管程的理由

Java本就从语言层面实现了管程，然而后面又在SDK中再次现实，这只能说明语言层面的实现的管程有所不足。要说谈synchronized的不足，我们就要要回顾一下破坏死锁的不可抢占问题：

破坏不可抢占条件，需要线程在获取不到锁的情况下主动释放它拥有的资源。当我们使用synchronized的时候，线程是没有办法主动释放它占有的资源的。因为，synchronized在申请不到资源时，会使线程直接进入阻塞状态，而线程进入了阻塞状态就不能主动释放占有的资源。

所以，有没有一种办法可以使得线程处于阻塞状态时也能够响应中断主动释放资源或者获取不到资源的时候不阻塞呢？答案是有的，使用SDK中的管程。

SDK中管程的实现java.util.concurrent中的Lock接口，提供了如下三种设计思想都可以解决死锁的不可抢占条件：

1. 能够响应中断

   线程处于阻塞状态时可以接收中断信号。我们便可以给阻塞的线程发送中断信号，唤醒线程，线程便有机会释放它曾经拥有的锁。这样便可破坏不可抢占条件。

2. 支持超时

   如果线程在一段时间之内没有获取到锁，不是进入阻塞状态，而是返回一个错误，那这个线程也有机会释放曾经持有的锁。这样也能破坏不可抢占条件。

3. 非阻塞地获取锁

   如果尝试获取锁失败，并不进入阻塞状态，而是直接返回，那这个线程也有机会释放曾经持有的锁。这样也可以破坏不可抢占条件。

这三种方案就可全面弥补synchronized的问题。也就是再造管程的原因。这三种思想体现在Lock接口的API上，便是如下三个方法：

// 支持中断的 API
void lockInterruptibly() throws InterruptedException;

// 支持超时的 API
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

// 支持非阻塞获取锁的 API
boolean tryLock();

下面我们便继续介绍Lock。

Lock和ReentrantLock

Lock接口中定义了一组抽象的加锁操作：

public interface Lock{
    void lock();
    void lockInterruptibly() throws InterruptedException;
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock();
    Condition newCondition(); // 关联Condition对象使用
}

与synchronized内置加锁不同，Lock提供的是无条件的、可轮询的、定时的以及可中断的锁获取操作，所有加锁和解锁都是显式的。在Lock的实现中必须要提供与内置锁相同的内存可见性语义，但是加锁语义、调度算法、顺序保证以及性能等方面可以不同。

ReentrantLock实现了Lock接口，并提供了与synchronized相同的互斥性和内存可见性。在获取ReentrantLock时，有着进入同步代码块相同的内存语义，在释放ReentrantLock时，同样有着与退出同步代码块相同的内存语义。见名知义，ReentrantLock还提供了同synchronized一样的可重入加锁的语义。