java.util.concurrent.locks包为锁和等待条件提供一个框架的接口和类，它不同于内置同步和监视器。该框架允许更灵活地使用锁和条件，但以更难用的语法为代价。
Lock 接口支持那些语义不同（重入、公平等）的锁规则，可以在非阻塞式结构的上下文（包括 hand-over-hand 和锁重排算法）中使用这些规则。主要的实现是 ReentrantLock。
ReadWriteLock 接口以类似方式定义了一些读取者可以共享而写入者独占的锁。此包只提供了一个实现，即 ReentrantReadWriteLock，因为它适用于大部分的标准用法上下文。但程序员可以创建自己的、适用于非标准要求的实现。
Condition 接口描述了可能会与锁有关联的条件变量。这些变量在用法上与使用 Object.wait 访问的隐式监视器类似，但提供了更强大的功能。需要特别指出的是，单个 Lock 可能与多个 Condition 对象关联。为了避免兼容性问题，Condition 方法的名称与对应的 Object 版本中的不同。
以下是locks包的相关类图：
在之前我们同步一段代码或者对象时都是使用 synchronized关键字，使用的是Java语言的内置特性，然而 synchronized的特性也导致了很多场景下出现问题，比如：
在一段同步资源上，首先线程A获得了该资源的锁，并开始执行，此时其他想要操作此资源的线程就必须等待。如果线程A因为某些原因而处于长时间操作的状态，比如等待网络，反复重试等等。那么其他线程就没有办法及时的处理它们的任务，只能无限制的等待下去。如果线程A的锁在持有一段时间后可自动被释放，那么其他线程不就可以使用该资源了吗？再有就是类似于数据库中的共享锁与排它锁，是否也可以应用到应用程序中？所以引入Lock机制就可以很好的解决这些问题。
Lock提供了比 synchronized更多的功能。但是要注意以下几点：
• Lock不是Java语言内置的，synchronized是Java语言的关键字，因此是内置特性。Lock是一个类，通过这个类可以实现同步访问；
• Lock和synchronized有一点非常大的不同，采用 synchronized不需要用户去手动释放锁，当synchronized方法或者 synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而 Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象。
一、Condition
Condition 将 Object 监视器方法（wait、notify 和 notifyAll）分解成截然不同的对象，以便通过将这些对象与任意 Lock 实现组合使用，为每个对象提供多个等待 set（wait-set）。其中，Lock 替代了 synchronized 方法和语句的使用，Condition 替代了 Object 监视器方法的使用。
Condition（也称为条件队列 或条件变量）为线程提供了一种手段，在某个状态条件下直到接到另一个线程的通知，一直处于挂起状态（即“等待”）。因为访问此共享状态信息发生在不同的线程中，所以它必须受到保护，因此要将某种形式的锁与 Condition相关联。
Condition 实例实质上被绑定到一个锁上。要为特定 Lock 实例获得 Condition 实例，可以使用其 newCondition() 方法，以下是API中的实例：
- import java.util.concurrent.locks.Condition;
- import java.util.concurrent.locks.Lock;
- import java.util.concurrent.locks.ReentrantLock;
- public class BoundedBuffer {
- final Lock lock = new ReentrantLock();// 锁对象
- final Condition notFull = lock.newCondition();// 写线程条件
- final Condition notEmpty = lock.newCondition();// 读线程条件
- final Integer[] items = new Integer[10];// 缓存队列
- int putptr/* 写索引 */, takeptr/* 读索引 */, count/* 队列中存在的数据个数 */;
- public void put(Integer x) throws InterruptedException {
- lock.lock();
- try {
- while (count == items.length)
- // 如果队列满了
- notFull.await();// 阻塞写线程
- items[putptr] = x;// 赋值
- System.out.println("写入：" + x);
- if (++putptr == items.length)
- putptr = 0;// 如果写索引写到队列的最后一个位置了，那么置为0
- ++count;// 个数++
- notEmpty.signal();// 唤醒读线程
- } finally {
- lock.unlock();
- }
- }
- public Integer take() throws InterruptedException {
- lock.lock();
- try {
- while (count == 0)
- // 如果队列为空
- notEmpty.await();// 阻塞读线程
- Integer x = items[takeptr];// 取值
- System.out.println("读取：" + x);
- if (++takeptr == items.length)
- takeptr = 0;// 如果读索引读到队列的最后一个位置了，那么置为0
- --count;// 个数--
- notFull.signal();// 唤醒写线程
- return x;
- } finally {
- lock.unlock();
- }
- }
- public static void main(String[] args) {
- final BoundedBuffer b = new BoundedBuffer();
- new Thread(new Runnable() {
- public void run() {
- int i = 0;
- while (true) {
- try {
- b.put(i++);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- }).start();
- new Thread(new Runnable() {
- public void run() {
- while (true) {
- try {
- b.take();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- }
- }).start();
- }
- }
- //结果：
- 写入：0
- 写入：1
- 写入：2
- 写入：3
- 写入：4
- 写入：5
- 写入：6
- 写入：7
- 写入：8
- 写入：9
- 读取：0
- 读取：1
- 读取：2
- 读取：3
- 读取：4
- 读取：5
- 读取：6
- 读取：7
- 读取：8
- 读取：9
- ...
- ...
- ...
作为一个示例，假定有一个绑定的缓冲区，它支持 put 和 take 方法。如果试图在空的缓冲区上执行 take 操作，则在某一个项变得可用之前（写操作前），线程将一直阻塞；如果试图在满的缓冲区上执行 put 操作，则在有空间变得可用之前（读操作前），线程将一直阻塞。从程序的运行结果就可以看出，缓冲区未满之前写操作持续进行，此时读操作会被阻塞无法读取数据。当缓冲区写满后写线程唤醒读线程，让其开始工作，此时读线程将缓冲区中的数据不断取出，直至缓冲区中所有数据都被取出，之后读线程进行等待并通知写操作开始工作。
在Condition中，用 await()代替 wait()，用 signal()代替 notify()，用 signalAll()代替 notifyAll()，传统线程的通信方式，Condition都可以实现，Condition的强大之处在于它可以为多个线程间建立不同的 Condition。
Condition 实现可以提供不同于 Object 监视器方法的行为和语义，比如受保证的通知排序，或者在执行通知时不需要保持一个锁。如果某个实现提供了这样特殊的语义，则该实现必须记录这些语义。
注意，Condition 实例只是一些普通的对象，它们自身可以用作 synchronized 语句中的目标，并且可以调用自己的 wait 和 notification 监视器方法。获取 Condition 实例的监视器锁或者使用其监视器方法，与获取和该 Condition 相关的 Lock 或使用其 waiting 和 signalling 方法没有什么特定的关系。为了避免混淆，建议除了在其自身的实现中之外，切勿以这种方式使用 Condition 实例。
除非另行说明，否则为任何参数传递 null 值将导致抛出 NullPointerException。
Condition方法不多，之前已经提到了await和 signal两个方法，以下是 Condition的全部方法：
- // 造成当前线程在接到信号或被中断之前一直处于等待状态。
- void await()
- // 造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
- boolean await(long time, TimeUnit unit)
- // 造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
- long awaitNanos(long nanosTimeout)
- // 造成当前线程在接到信号之前一直处于等待状态。
- void awaitUninterruptibly()
- // 造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。
- boolean awaitUntil(Date deadline)
- // 唤醒一个等待线程。
- void signal()
- // 唤醒所有等待线程。
- void signalAll()
Condition 接口有两个已知实现类：
- AbstractQueuedLongSynchronizer.ConditionObject
- AbstractQueuedSynchronizer.ConditionObject
AbstractQueuedLongSynchronizer 的属性和方法与 AbstractQueuedSynchronizer 完全相同，但所有与状态相关的参数和结果都定义为 long 而不是 int。当创建需要 64 位状态的多级别锁和屏障等同步器时，此类很有用。因为两个类基本相同，所以本文就只以 AbstractQueuedSynchronizer 的实现为例。
在等待 Condition 时，允许发生“虚假唤醒”，这通常作为对基础平台语义的让步。对于大多数应用程序，这带来的实际影响很小，因为 Condition 应该总是在一个循环中被等待，并测试正被等待的状态声明。某个实现可以随意移除可能的虚假唤醒，但建议应用程序程序员总是假定这些虚假唤醒可能发生，因此总是在一个循环中等待。
二、Lock
Lock也是一个接口，它 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作。此实现允许更灵活的结构，可以具有差别很大的属性，可以支持多个相关的 Condition 对象。
Lock 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作。此实现允许更灵活的结构，可以具有差别很大的属性，可以支持多个相关的 Condition 对象。
锁是控制多个线程对共享资源进行访问的工具。通常，锁提供了对共享资源的独占访问。一次只能有一个线程获得锁，对共享资源的所有访问都需要首先获得锁。不过，某些锁可能允许对共享资源并发访问，如 ReadWriteLock 的读取锁。
synchronized 方法或语句的使用提供了对与每个对象相关的隐式监视器锁的访问，但却强制所有锁获取和释放均要出现在一个块结构中：当获取了多个锁时，它们必须以相反的顺序释放，且必须在与所有锁被获取时相同的词法范围内释放所有锁。
虽然 synchronized 方法和语句的范围机制使得使用监视器锁编程方便了很多，而且还帮助避免了很多涉及到锁的常见编程错误，但有时也需要以更为灵活的方式使用锁。例如，某些遍历并发访问的数据结果的算法要求使用 "hand-over-hand" 或 "chain locking"：获取节点 A 的锁，然后再获取节点 B 的锁，然后释放 A 并获取 C，然后释放 B 并获取 D，依此类推。Lock 接口的实现允许锁在不同的作用范围内获取和释放，并允许以任何顺序获取和释放多个锁，从而支持使用这种技术。
随着灵活性的增加，也带来了更多的责任。不使用块结构锁就失去了使用 synchronized 方法和语句时会出现的锁自动释放功能。在大多数情况下，应该使用以下语句：
- Lock lock = 某实现;
- //获取锁
- lock.lock();
- try {
- // 访问此锁保护的资源
- } finally {
- //释放锁
- lock.unlock();
- }
锁定和取消锁定出现在不同作用范围中时，必须谨慎地确保保持锁定时所执行的所有代码用 try-finally 或 try-catch 加以保护，以确保在必要时释放锁。
Lock 实现提供了使用 synchronized 方法和语句所没有的其他功能，包括提供了一个非块结构的获取锁尝试 (tryLock())、一个获取可中断锁的尝试 (lockInterruptibly()) 和一个获取超时失效锁的尝试 (tryLock(long, TimeUnit))。
Lock 类还可以提供与隐式监视器锁完全不同的行为和语义，如保证排序、非重入用法或死锁检测。如果某个实现提供了这样特殊的语义，则该实现必须对这些语义加以记录。
注意，Lock 实例只是普通的对象，其本身可以在 synchronized 语句中作为目标使用。获取 Lock 实例的监视器锁与调用该实例的任何 lock() 方法没有特别的关系。为了避免混淆，建议除了在其自身的实现中之外，决不要以这种方式使用 Lock 实例。
除非另有说明，否则为任何参数传递 null 值都将导致抛出 NullPointerException。
Lock接口有6个方法，分别是：
- // 获取锁
- void lock()
- // 如果当前线程未被中断，则获取锁
- void lockInterruptibly()
- // 返回绑定到此 Lock 实例的新 Condition 实例
- Condition newCondition()
- // 仅在调用时锁为空闲状态才获取该锁
- boolean tryLock()
- // 如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁
- boolean tryLock(long time, TimeUnit unit)
- // 释放锁
- void unlock()
其中 lock与 unlock是最常用的方法，分别是获取与释放锁。
以下是几个方法的详细解释及用法。
1.newCondition() 方法
返回绑定到此 Lock 实例的新 Condition 实例。 在等待条件前，锁必须由当前线程保持。调用 Condition.await() 将在等待前以原子方式释放锁，并在等待返回前重新获取锁。 实现时需要注意：Condition 实例的具体操作依赖于 Lock 实现，并且该实现必须对此加以记录。
2.lock() 方法
获取锁，如果锁已被其他线程获取，则进行等待。
如果锁不可用，出于线程调度目的，将禁用当前线程，并且在获得锁之前，该线程将一直处于休眠状态。之前已经说过如果采用Lock，必须主动去释放锁，并且在发生异常时，并不会自动释放锁。所以将释放锁的操作放在 try-finally 或 try-catch块中进行，以保证锁一定被被释放，防止死锁的发生。
以下是一个示例来表现未释放锁的情况下的代码执行情况：
- import java.util.concurrent.locks.Lock;
- import java.util.concurrent.locks.ReentrantLock;
- public class LockThread {
- Lock lock = new ReentrantLock();
- public void lock(String name) {
- // 获取锁
- lock.lock();
- try {
- System.out.println(name + " get the lock");
- // 访问此锁保护的资源
- } finally {
- // 释放锁
- //lock.unlock();
- //System.out.println(name + " release the lock");
- }
- }
- public static void main(String[] args) {
- final LockThread lt = new LockThread();
- new Thread(new Runnable() {
- public void run() {
- lt.lock("A");
- }
- }).start();
- new Thread(new Runnable() {
- public void run() {
- lt.lock("B");
- }
- }).start();
- }
- }
- //结果：
- A get the lock
从结果就可以清晰的看到，A线程获取锁之后并没有主动释放锁，然后 B线程开始执行，此时 B尝试获取锁，因为 A还是锁的持有者，所以 B只好等待。
将注释去掉，打印出来的正常结果应该是：
- A get the lock
- A release the lock
- B get the lock
- B release the lock
3.unlock() 方法
释放锁。
实现时需要注意：Lock 实现通常对哪个线程可以释放锁施加了限制（通常只有锁的保持者可以释放它），如果违背了这个限制，可能会抛出（未经检查的）异常。该 Lock 实现必须对所有限制和异常类型进行记录。
4.tryLock() 方法
仅在调用时锁为空闲状态才获取该锁。
如果锁可用，则获取锁，并立即返回值 true。如果锁不可用，则此方法将立即返回值 false。 也就说这个方法无论如何都会立即返回，在拿不到锁时不会一直在那等待，这点与lock不同。
tryLock的典型使用方法如下：
- Lock lock = 某锁实现;
- //尝试获取锁
- if (lock.tryLock()) {
- //如果成功则已获取锁
- try {
- // 操作被保护数据
- } finally {
- //释放锁
- lock.unlock();
- }
- } else {
- //获取锁失败
- }
此用法可确保如果获取了锁，则会释放锁，如果未获取锁，则不会试图将其释放。
5.tryLock(long time, TimeUnit unit) 方法
如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁。
tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。
如果锁不可用，出于线程调度目的，将禁用当前线程，并且在发生以下三种情况之一前，该线程将一直处于休眠状态：
• 锁由当前线程获得；
• 其他某个线程中断当前线程，并且支持对锁获取的中断；
• 已超过指定的等待时间。
如果当前线程：
• 在进入此方法时已经设置了该线程的中断状态；
• 在获取锁时被中断，并且支持对锁获取的中断， 则将抛出 InterruptedException，并会清除当前线程的已中断状态。
如果超过了指定的等待时间，则将返回值 false。如果 time 小于等于 0，该方法将完全不等待。
实现时需要注意：在某些实现中可能无法中断锁获取，即使可能，该操作的开销也很大。程序员应该知道可能会发生这种情况。在这种情况下，该实现应该对此进行记录。
相对于普通方法返回而言，实现可能更喜欢响应某个中断，或者报告出现超时情况。
Lock 实现可能可以检测锁的错误用法，例如，某个调用可能导致死锁，在特定的环境中可能抛出（未经检查的）异常。该 Lock 实现必须对环境和异常类型进行记录。
6.lockInterruptibly() 方法
如果当前线程未被中断，则获取锁。
lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过 lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用 threadB.interrupt()方法能够中断线程B的等待过程。
如果锁可用，则获取锁，并立即返回。 如果锁不可用，出于线程调度目的，将禁用当前线程，并且在发生以下两种情况之一以前，该线程将一直处于休眠状态：
• 锁由当前线程获得；
• 其他某个线程中断当前线程，并且支持对锁获取的中断。
如果当前线程：
• 在进入此方法时已经设置了该线程的中断状态；
• 在获取锁时被中断，并且支持对锁获取的中断， 则将抛出 InterruptedException，并清除当前线程的已中断状态。
实现时需要注意：在某些实现中可能无法中断锁获取，即使可能，该操作的开销也很大。程序员应该知道可能会发生这种情况。在这种情况下，该实现应该对此进行记录。
相对于普通方法返回而言，实现可能更喜欢响应某个中断。 Lock 实现可能可以检测锁的错误用法，例如，某个调用可能导致死锁，在特定的环境中可能抛出（未经检查的）异常。该 Lock 实现必须对环境和异常类型进行记录。
由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出InterruptedException。所以 lockInterruptibly()一般这样使用：
- try {
- // 获取锁
- lock.lockInterruptibly();
- // 访问此锁保护的资源
- } catch (InterruptedException e) {
- e.printStackTrace();
- } finally {
- // 释放锁
- lock.unlock();
- }
三、ReadWriteLock
ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有 writer，读取锁可以由多个 reader 线程同时保持，而写入锁是独占的。
所有 ReadWriteLock 实现都必须保证 writeLock 操作的内存同步效果也要保持与相关 readLock 的联系。也就是说，成功获取读锁的线程会看到写入锁之前版本所做的所有更新。
与互斥锁相比，读-写锁允许对共享数据进行更高级别的并发访问。虽然一次只有一个线程（writer 线程）可以修改共享数据，但在许多情况下，任何数量的线程可以同时读取共享数据（reader 线程），读-写锁利用了这一点。从理论上讲，与互斥锁相比，使用读-写锁所允许的并发性增强将带来更大的性能提高。在实践中，只有在多处理器上并且只在访问模式适用于共享数据时，才能完全实现并发性增强。
与互斥锁相比，使用读-写锁能否提升性能则取决于读写操作期间读取数据相对于修改数据的频率，以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数。例如，某个最初用数据填充并且之后不经常对其进行修改的 collection，因为经常对其进行搜索（比如搜索某种目录），所以这样的 collection 是使用读-写锁的理想候选者。但是，如果数据更新变得频繁，数据在大部分时间都被独占锁，这时，就算存在并发性增强，也是微不足道的。更进一步地说，如果读取操作所用时间太短，则读-写锁实现（它本身就比互斥锁复杂）的开销将成为主要的执行成本，在许多读-写锁实现仍然通过一小段代码将所有线程序列化时更是如此。最终，只有通过分析和测量，才能确定应用程序是否适合使用读-写锁。
ReadWriteLock 接口非常简单，只有两个方法：
- //返回用于读取操作的锁
- Lock readLock()
- //返回用于写入操作的锁
- Lock writeLock()
尽管读-写锁的基本操作是直截了当的，但实现仍然必须作出许多决策，这些决策可能会影响给定应用程序中读-写锁的效果。这些策略的例子包括：
• 在 writer 释放写入锁时，reader 和 writer 都处于等待状态，在这时要确定是授予读取锁还是授予写入锁。Writer 优先比较普遍，因为预期写入所需的时间较短并且不那么频繁。Reader 优先不太普遍，因为如果 reader 正如预期的那样频繁和持久，那么它将导致对于写入操作来说较长的时延。公平或者“按次序”实现也是有可能的。
• 在 reader 处于活动状态而 writer 处于等待状态时，确定是否向请求读取锁的 reader 授予读取锁。Reader 优先会无限期地延迟 writer，而 writer 优先会减少可能的并发。
• 确定是否重新进入锁：可以使用带有写入锁的线程重新获取它吗？可以在保持写入锁的同时获取读取锁吗？可以重新进入写入锁本身吗？
• 可以将写入锁在不允许其他 writer 干涉的情况下降级为读取锁吗？可以优先于其他等待的 reader 或 writer 将读取锁升级为写入锁吗？
虽然接口简单，但是实现需要考虑的问题还是非常多的，在下一篇锁的实现中会再详细介绍读-写锁知识。
以上就是三个接口的一些入门介绍，下一篇会学习这些接口的相关实现类。
来源：oschina
链接：https://my.oschina.net/u/873167/blog/672484