java.util.concurrent.locks包为锁和等待条件提供一个框架的接口和类，它不同于内置同步和监视器。该框架允许更灵活地使用锁和条件，但以更难用的语法为代价。
Lock 接口支持那些语义不同（重入、公平等）的锁规则，可以在非阻塞式结构的上下文（包括 hand-over-hand 和锁重排算法）中使用这些规则。主要的实现是 ReentrantLock。
ReadWriteLock 接口以类似方式定义了一些读取者可以共享而写入者独占的锁。此包只提供了一个实现，即 ReentrantReadWriteLock，因为它适用于大部分的标准用法上下文。但程序员可以创建自己的、适用于非标准要求的实现。
LockSupport 类提供了更低级别的阻塞和解除阻塞支持，这对那些实现自己的定制锁类的开发人员很有用。
一、锁的概念
1.可重入锁
可重入锁，也叫做递归锁，指的是同一线程外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。也就是说如果当前线程已经获得了某个监视器对象所持有的锁，那么该线程在该方法中调用另外一个同步方法也同样持有该锁。
如果锁具备可重入性，则称作为可重入锁。像 synchronized和 ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个 synchronized方法时，比如说 methodA，而在 methodA中会调用另外一个synchronized方法 methodB，此时线程不必重新去申请锁，而是可以直接执行方法 methodB。
如以下情况：
public synchronized void methodA() {
// 調用相同监视器对象中的其他 synchronized方法
this.methodB();
}
public synchronized void methodB() {
// 其他代码
}因为进入 methodA时已经获得了该监视器对象持有的锁，当从 methodA跳转到 methodB时就不必再去获取锁了。
所以使用以上代码修改后的示例为：
public class LockTest implements Runnable {
public synchronized void methodA() {
System.out.println("methodA:" + Thread.currentThread().getId());
// 调用同线程内另一个 synchronized方法
methodB();
}
public synchronized void methodB() {
System.out.println("methodB:" + Thread.currentThread().getId());
}
public void run() {
methodA();
}
public static void main(String[] args) {
LockTest lt = new LockTest();
new Thread(lt).start();
new Thread(lt).start();
}
}
//结果：
methodA:9
methodB:9
methodA:10
methodB:10假如 synchronized不具备可重入性，此时 methodA线程就需要重新申请锁。但是这就会造成一个问题，因为 methodA线程已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会造成 methodA线程一直等待永远不会获取到的锁。
所以可重入锁最大的作用是避免死锁。
2.可中断锁
顾名思义，就是在某些条件下可以相应中断的锁。
在Java中，synchronized就不是可中断锁，而 Lock是可中断锁。
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。
上一篇文章已经介绍过 lockInterruptibly()方法的使用场景，所以 lockInterruptibly()的用法就体现了 Lock的可中断性。
以下是中断锁的一个示例应用：
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class LockTest implements Runnable {
private Lock lock = new ReentrantLock();
public void methodA() throws InterruptedException {
lock.lockInterruptibly(); // 如果抛出InterruptedException异常说明已经被中断，需要在外层判断处理
try {
System.out.println(Thread.currentThread().getName() + " 获得锁");
long startTime = System.currentTimeMillis();
// 等待5秒
for (;;) {
if (System.currentTimeMillis() - startTime >= 5000)
break;
}
} finally {
lock.unlock();
System.out.println(Thread.currentThread().getName() + " 释放锁");
}
}
public void run() {
try {
methodA();
} catch (InterruptedException e) {
System.out.println(Thread.currentThread().getName() + " 被中断");
}
}
public static void main(String[] args) {
LockTest lt = new LockTest();
Thread t1 = new Thread(lt);
Thread t2 = new Thread(lt);
t1.start();
t2.start();
t2.interrupt();
}
}
//结果：
Thread-0 获得锁
Thread-1 被中断
Thread-0 释放锁当调用 lockInterruptibly()方法中断锁的获取时，会抛出 InterruptedException异常。这里不应该使用catch捕获异常，否则将继续执行 lockInterruptibly()方法之后的代码，从而报未获取锁的错误。应向外层抛出该异常以证明获取锁操作已经被中断，从而进行其他处理。
3.公平锁
公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。
而非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。
在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。
而对于 ReentrantLock和 ReentrantReadWriteLock，它默认情况下是非公平锁，但是在初始化时可以设置为公平锁。
Lock lock=new ReentrantLock(true);在 ReentrantLock中定义了2个静态内部类，一个是 NotFairSync，一个是 FairSync，分别用来实现非公平锁和公平锁。ReentrantLock中还有很多与这两种锁相关的方法，在下面的章节中会逐一介绍。
4.读写锁
读写锁实际是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作。这种锁相对于自旋锁而言，能提高并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最大可能的读者数为实际的逻辑CPU数。写者是排他性的，一个读写锁同时只能有一个写者或多个读者（与CPU数相关），但不能同时既有读者又有写者。
正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。
ReadWriteLock就是读写锁接口，ReentrantReadWriteLock是这个接口的实现。
可以通过 readLock()获取读锁，通过 writeLock()获取写锁。
几种常用的锁类型已经了解，接下来就从具体实现来入手，深入学习它们的用法及原理。
二、ReentrantLock
1.简介
java.util.concurrent.lock 中的 Lock 框架是锁的一个抽象，它允许把锁定的实现作为 Java 类，而不是作为语言的特性来实现。这就为 Lock 的多种实现留下了空间，各种实现可能有不同的调度算法、性能特性或者锁定语义。 ReentrantLock 类实现了 Lock ，它拥有与 synchronized 相同的并发性和内存语义，但是添加了类似轮询锁、定时锁等候和可中断锁等候的一些特性。此外，它还提供了在激烈争用情况下更佳的性能。（换句话说，当许多线程都想访问共享资源时，JVM 可以花更少的时候来调度线程，把更多时间用在执行线程上）
ReentrantLock是一个可重入的互斥锁 Lock，它具有与使用 synchronized 方法和语句所访问的隐式监视器锁相同的一些基本行为和语义，但功能更强大。
可重入锁意味着什么呢？简单来说，它有一个与锁相关的获取计数器，如果拥有锁的某个线程再次得到锁，那么获取计数器就加1，然后锁需要被释放两次才能获得真正释放。这模仿了 synchronized 的语义；如果线程进入由线程已经拥有的监控器保护的 synchronized 块，就允许线程继续进行，当线程退出第二个（或者后续） synchronized 块的时候，不释放锁，只有线程退出它进入的监控器保护的第一个 synchronized 块时，才释放锁。
ReentrantLock 将由最近成功获得锁，并且还没有释放该锁的线程所拥有。当锁没有被另一个线程所拥有时，调用 lock 的线程将成功获取该锁并返回。如果当前线程已经拥有该锁，此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。
2.构造方法
ReentrantLock类的构造方法接受一个可选的公平（fair）参数。当设置为 true 时，在多个线程的争用下，这些锁倾向于将访问权授予等待时间最长的线程。否则此锁将无法保证任何特定访问顺序。与采用默认设置（使用不公平锁）相比，使用公平锁的程序在许多线程访问时表现为很低的总体吞吐量（即速度很慢，常常极其慢），但是在获得锁和保证锁分配的均衡性时差异较小。不过要注意的是，公平锁不能保证线程调度的公平性。因此，使用公平锁的众多线程中的一员可能获得多倍的成功机会，这种情况发生在其他活动线程没有被处理并且目前并未持有锁时。还要注意的是，未定时的 tryLock 方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁是可用的，此方法就可以获得成功。
以下是 ReentrantLock的两种构造方法：
/**
* 创建 ReentrantLock实例，相当于使用 new ReentrantLock(false);
*/
public ReentrantLock() {
sync = new NonfairSync();
}
/**
* 根据指定的公平策略创建 ReentrantLock实例
*/
public ReentrantLock(boolean fair) {
sync = (fair) ? new FairSync() : new NonfairSync();
}默认构造方法相当于构建了一个非公平策略的 ReentrantLock实例。
3.ReentrantLock使用
1）lock()方法
之前已经有相关实例展现了 lock()方法的使用，使用 lock方法值得注意的是需要在finally块中主动释放锁，否则其他线程将阻塞。
public class LockThread {
Lock lock = new ReentrantLock();
public void lock() {
// 获取锁
try {
lock.lock();
System.out.println(Thread.currentThread().getName() + " get the lock");
} finally {
// 释放锁
lock.unlock();
System.out.println(Thread.currentThread().getName() + " release the lock");
}
}
public static void main(String[] args) {
final LockThread lt = new LockThread();
new Thread(new Runnable() {
public void run() {
lt.lock();
}
}).start();
new Thread(new Runnable() {
public void run() {
lt.lock();
}
}).start();
}
}
//结果：
Thread-0 get the lock
Thread-0 release the lock
Thread-1 get the lock
Thread-1 release the lock
2）unlock()方法
unlock方法需要配合 lock()方法使用，unlock方法需要在 catch或 finally块中声明。当未获得锁时，使用unlock方法会抛出 IllegalMonitorStateException异常。
注释以上代码中 lock方法，将产生以下结果：
Exception in thread "Thread-0" java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1175)
at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at LockThread.lock(LockThread.java:14)
at LockThread$1.run(LockThread.java:23)
at java.lang.Thread.run(Thread.java:619)
Exception in thread "Thread-1" java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:127)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1175)
at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at LockThread.lock(LockThread.java:14)
at LockThread$2.run(LockThread.java:28)
at java.lang.Thread.run(Thread.java:619)3）tryLock()方法
tryLock方法仅在调用时锁未被另一个线程保持的情况下，才获取该锁。
如果该锁没有被另一个线程保持，并且立即返回 true 值，则将锁的保持计数设置为 1。即使已将此锁设置为使用公平排序策略，但是调用 tryLock() 仍将 立即获取锁（如果有可用的），而不管其他线程当前是否正在等待该锁。在某些情况下，此“闯入”行为可能很有用，即使它会打破公平性也如此。如果希望遵守此锁的公平设置，则使用 tryLock(0, TimeUnit.SECONDS) ，它几乎是等效的（也检测中断）。
如果当前线程已经保持此锁，则将保持计数加 1，该方法将返回 true。 如果锁被另一个线程保持，则此方法将立即返回 false 值。
示例代码如下：
public class LockThread {
Lock lock = new ReentrantLock();
public void lock() {
// 尝试获取锁
if (lock.tryLock()) {
try {
System.out.println(Thread.currentThread().getName() + " get the lock");
while (true) {
//block here
}
} finally {
// 释放锁
lock.unlock();
System.out.println(Thread.currentThread().getName() + " release the lock");
}
} else {
System.out.println(Thread.currentThread().getName() + " get the lock fail");
}
}
public static void main(String[] args) {
final LockThread lt = new LockThread();
new Thread(new Runnable() {
public void run() {
lt.lock();
}
}).start();
new Thread(new Runnable() {
public void run() {
lt.lock();
}
}).start();
}
}
//结果：
Thread-0 get the lock
Thread-1 get the lock fail
其中利用 while循环产生阻塞，导致 Thread-0线程无法释放锁。当 Thread-1利用 tryLock方法尝试获取锁时，发现锁暂时无法被获取，tryLock方法返回 false，获取锁失败。
4）tryLock(long timeout, TimeUnit unit)方法
如果锁在给定等待时间内没有被另一个线程保持，且当前线程未被中断，则获取该锁。
如果该锁没有被另一个线程保持，并且立即返回 true 值，则将锁的保持计数设置为 1。如果为了使用公平的排序策略，已经设置此锁，并且其他线程都在等待该锁，则不会 获取一个可用的锁。这与 tryLock() 方法相反。如果想使用一个允许闯入公平锁的定时 tryLock，那么可以将定时形式和不定时形式组合在一起：
if (lock.tryLock() || lock.tryLock(timeout, unit) ) {
...
}
如果当前线程已经保持此锁，则将保持计数加 1，该方法将返回 true。如果超出了指定的等待时间，则返回值为 false。如果该时间小于等于 0，则此方法根本不会等待。
将tryLock部分示例中的lock方法代码修改为：
public void lock() {
try {
// 尝试10秒内获取锁
if (lock.tryLock() || lock.tryLock(10L, TimeUnit.SECONDS)) {
try {
System.out.println(Thread.currentThread().getName() + " get the lock");
} finally {
long startTime = System.currentTimeMillis();
for (;;) {
if (System.currentTimeMillis() - startTime >= 5000) {
// 释放锁
System.out.println(Thread.currentThread().getName() + " release the lock");
lock.unlock();
break;
}
}
}
} else {
System.out.println(Thread.currentThread().getName() + " get the lock fail");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
//结果：
Thread-0 get the lock
Thread-0 release the lock
Thread-1 get the lock
Thread-1 release the lock结果打印正确。如果将阻塞时间修改的比 tryLock方法时间要长，则结果为：
Thread-0 get the lock
Thread-1 get the lock fail
Thread-0 release the lock5）lockInterruptibly()方法
如果当前线程未被中断，则获取锁。
如果该锁没有被另一个线程保持，则获取该锁并立即返回，将锁的保持计数设置为 1。
如果当前线程已经保持此锁，则将保持计数加 1，并且该方法立即返回。
如果锁被另一个线程保持，则出于线程调度目的，禁用当前线程，并且在发生以下两种情况之一以前，该线程将一直处于休眠状态：
• 锁由当前线程获得；或者
• 其他某个线程中断当前线程。
如果当前线程获得该锁，则将锁保持计数设置为 1。
如果当前线程：
• 在进入此方法时已经设置了该线程的中断状态；或者
• 在等待获取锁的同时被中断。
则抛出 InterruptedException，并且清除当前线程的已中断状态。
在此实现中，因为此方法是一个显式中断点，所以要优先考虑响应中断，而不是响应锁的普通获取或重入获取。
lockInterruptibly方法的示例在本文刚开始时已经展现，这里就不再复述了。
6）getHoldCount()方法
查询当前线程保持此锁的次数。
对于与解除锁操作不匹配的每个锁操作，线程都会保持一个锁。
保持计数信息通常只用于测试和调试。例如，如果不应该使用已经保持的锁进入代码的某一部分，则可以声明如下：
ReentrantLock lock = new ReentrantLock();
assert lock.getHoldCount() == 0;
lock.lock();
try {
// ...
} finally {
lock.unlock();
}其中 assert关键字用法如下：
（1）assert
如果
如果为false，则程序抛出AssertionError，并终止执行。
（2）assert
如果
如果为false，则程序抛出java.lang.AssertionError，并输入<错误信息表达式>。
三、ReentrantLock内部类
1.ReentrantLock.Sync类
可重入锁内部实现的超类，主要实现了公平与非公平锁的共有方法，并提供了加锁操作的统一抽象：abstract void lock();，还有核心的释放锁的操作。Sync类是 ReentrantLock的内部类，继承自 AbstractQueuedSynchronizer类。可以看到，ReentrantLock都是把具体实现委托给内部类而不是直接继承自 AbstractQueuedSynchronizer，这样的好处是用户不会看到不需要的方法，也避免了用户错误地使用 AbstractQueuedSynchronizer的公开方法而导致错误。
ReentrantLock的重入计数是使用 AbstractQueuedSynchronizer的state属性的，state大于0表示锁被占用、等于0表示空闲，小于0则是重入次数太多导致溢出了。
Sync类是该锁的同步控制基础。Sync子类实现了公平与非公平两个版本。
其中：
• AbstractOwnableSynchronizer：保持和获取独占线程。
• AbstractQueuedSynchronizer：以虚拟队列的方式管理线程的锁获取与锁释放，以及各种情况下的线程中断。提供了默认的同步实现，但是获取锁和释放锁的实现定义为抽象方法，由子类实现。目的是使开发人员可以自由定义获取锁以及释放锁的方式。
• Sync：ReentrantLock的内部抽象类，实现了简单的获取锁和释放锁。
• NonfairSync和 FairSync：分别表示“非公平锁”和“公平锁”，都继承于 Sync，并且都是 ReentrantLock的内部类。
• ReentrantLock：实现了 Lock接口的 lock-unlock方法，根据 fair参数决定使用 NonfairSync还是FairSync。
Sync类中比较重要的实现方法有：nonfairTryAcquire，tryRelease等。
以下是 Sync的源代码：
static abstract class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
/**
* 执行Lock.lock()方法，留给子类根据其公平性实现 子类化的最主要原因是允许非公平的快速路径
*/
abstract void lock();
/**
* 非公平获取实现
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 如果锁是空闲的，进行加锁必须用CAS操作来确保即使有多个线程竞争锁也是安全的
if (compareAndSetState(0, acquires)) {
// 把当前线程设为锁的持有者，在获取前可用于判断是否是重入。
setExclusiveOwnerThread(current);
return true;
}
} else if (current == getExclusiveOwnerThread()) {
// 如果锁被占用且当前线程是锁的持有者，说明是重入。
int nextc = c + acquires;
if (nextc < 0)
// 溢出，加锁次数从0开始，加锁与释放操作是对称的，所以绝不会是小于0值，小于0只能是溢出。
throw new Error("Maximum lock count exceeded");
// 锁被持有的情况下，只有持有者才能更新锁保护的资源，所以这里不需要用CAS操作。
setState(nextc);
return true;
}
return false;
}
/**
* 尝试释放锁
*/
protected final boolean tryRelease(int releases) {
// 先读取state是为了获得一个读屏障，owner不是volatile的。
int c = getState() - releases;
// 只有锁的持有者才能释放锁
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {// 锁重入计数减到0，需要真正释放锁了。
free = true;
setExclusiveOwnerThread(null);
}
// 如果c为0，写操作完成后，其他线程就会看到锁被释放了，所以 setExclusiveOwnerThread必须在这个写之前完成。
setState(c);
return free;
}
/**
* 判断当前线程是否为锁的持有者
*/
protected final boolean isHeldExclusively() {
return getExclusiveOwnerThread() == Thread.currentThread();
}
/**
* 创建新的 Condition实例
*/
final ConditionObject newCondition() {
return new ConditionObject();
}
/**
* 获取锁持有者
*/
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
/**
* 获取加锁次数
*/
final int getHoldCount() {
// 以state属性作为加锁次数
return isHeldExclusively() ? getState() : 0;
}
/**
* 是否获取锁
*/
final boolean isLocked() {
// 加锁次数为0表示没有被拥有
return getState() != 0;
}
/**
*
* 从流中重新构建锁实例
*/
private void readObject(java.io.ObjectInputStream s) throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // 重置为未锁定状态
}
}其中 compareAndSetState方法的作用是：如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。
setExclusiveOwnerThread方法的作用是：设置当前拥有独占访问的线程。null 参数表示没有线程拥有访问。
其他方法的作用已经在注释中体现了。
2.ReentrantLock.NonfairSync与 ReentrantLock.FairSync
NonfairSync与 FairSync均继承于 Sync类，两个类主要的区别是lock() 方法与 tryAcquire(int)的具体实现。
首先是 NonfairSync类：
/**
* 非公平锁 Sync实现
*/
final static class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* 执行lock，尝试立即进入，失败就退回常规流程
*/
final void lock() {
// 首先进行状态设置
if (compareAndSetState(0, 1))
// 如果状态设置成功，把当前线程设为锁持有者
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
/**
* 调用非公平版本获取
*/
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}然后是 FairSync类，FairSync类提供公平性的锁实现。实现公平性的关键在于：如果锁被占用且当前线程不是持有者也不是等待队列的第一个，则进入等待队列。
/**
* 公平锁 Sync实现
*/
final static class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
/**
* 获取锁
*/
final void lock() {
// acquire方法会先调用 tryAcquire，所以公平策略的控制留给 tryAcquire
acquire(1);
}
/**
* 公平版本 tryAcquire，除非是递归调用或没有等待者或者是第一个，否则不授予访问
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 与非公平的不同就是要判断当前线程是否为首节点
if (isFirst(current) && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
// 如果为重入
} else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;// 重入次数增加
if (nextc < 0)// 溢出，重入次数太多，在改变状态之前抛出异常以确保锁的状态是正确的
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
NonfairSync与 FairSync不同在于：
lock方法中
NonfairSync是:如果原状态为0，则设置为新值1，如果设置成功，直接得到锁；如果设置失败则执行与FairSync流程相同的操作。
FairSync则是:先尝试去获取锁,如果得到了锁则设置状态值为1。
重入锁方面两个方法表现一样。
tryAcquire方法中
FairSync会比 NonfairSync多判断一个 isFirst(current)条件。
isFirst源代码为：
final boolean isFirst(Thread current) {
Node h, s;
return ((h = head) == null || ((s = h.next) != null && s.thread == current) || fullIsFirst(current));
}线程为首结点需要满足以下条件：
1）等待队列为空。
2）等待队列 head的 next结点的 thread为当前线程（head.next.thread = currentThread)，即线程为等待队列除哑结点外的第一个结点。
3）等待队列 head结点到某个结点（暂命名为结点s），之间的所有结点的thread变量为 null，且结点s的thread为当前线程。
四、ReentrantLock 与 synchronized的选择
1）比较 ReentrantLock 和 synchronized 的可伸缩性
引用自网络的测试结果：
两图总结了不同线程数量的结果。这个评测并不完美，而且只在两个系统上运行了（一个是双 Xeon 运行超线程 Linux，另一个是单处理器 Windows 系统），但是，应当足以表现 synchronized 与 ReentrantLock 相比所具有的伸缩性优势了。
两图中的图表以每秒调用数为单位显示了吞吐率，把不同的实现调整到 1 线程 synchronized 的情况。每个实现都相对迅速地集中在某个稳定状态的吞吐率上，该状态通常要求处理器得到充分利用，把大多数的处理器时间都花在处理实际工作（计算机随机数）上，只有小部分时间花在了线程调度开支上。我们注意到，synchronized 版本在处理任何类型的争用时，表现都相当差，而 Lock 版本在调度的开支上花的时间相当少，从而为更高的吞吐率留下空间，实现了更有效的 CPU 利用。
2）条件变量
类 Object 包含某些特殊的方法，用来在线程的 wait() 、 notify() 和 notifyAll() 之间进行通信。这些是高级的并发性特性，许多开发人员从来没有用过它们 —— 这可能是件好事，因为它们相当微妙，很容易使用不当。幸运的是，随着 JDK 5.0 中引入 java.util.concurrent ，开发人员几乎更加没有什么地方需要使用这些方法了。
通知与锁定之间有一个交互 —— 为了在对象上 wait 或 notify ，您必须持有该对象的锁。就像 Lock 是同步的概括一样， Lock 框架包含了对 wait 和 notify 的概括，这个概括叫作 条件（Condition） 。 Lock 对象则充当绑定到这个锁的条件变量的工厂对象，与标准的 wait 和 notify 方法不同，对于指定的 Lock ，可以有不止一个条件变量与它关联。这样就简化了许多并发算法的开发。例如， 条件（Condition） 的 Javadoc 显示了一个有界缓冲区实现的示例，该示例使用了两个条件变量，“not full”和“not empty”，它比每个 lock 只用一个 wait 设置的实现方式可读性要好一些（而且更有效）。 Condition 的方法与 wait 、 notify 和 notifyAll 方法类似，分别命名为 await 、 signal 和 signalAll ，因为它们不能覆盖 Object 上的对应方法。
3）公平与非公平
ReentrantLock 构造器的一个参数是 boolean fair值，它允许您选择想要一个 公平（fair）锁，还是一个 不公平（unfair）锁。公平锁使线程按照请求锁的顺序依次获得锁；而不公平锁则允许直接获取锁，在这种情况下，线程有时可以比先请求锁的其他线程先得到锁。注意 synchronized 是非公平锁。
为什么我们不让所有的锁都公平呢？毕竟，公平是好事，不公平是不好的，不是吗？（当孩子们想要一个决定时，总会叫嚷“这不公平”。我们认为公平非常重要，孩子们也知道。）在现实中，公平保证了锁是非常健壮的锁，有很大的性能成本。要确保公平所需要的记帐（bookkeeping）和同步，就意味着被争夺的公平锁要比不公平锁的吞吐率更低。作为默认设置，应当把公平设置为 false ，除非公平对您的算法至关重要，需要严格按照线程排队的顺序对其进行服务。
那么同步又如何呢？内置的监控器锁是公平的吗？答案令许多人感到大吃一惊，它们是不公平的，而且永远都是不公平的。但是没有人抱怨过线程饥渴，因为 JVM 保证了所有线程最终都会得到它们所等候的锁。确保统计上的公平性，对多数情况来说，这就已经足够了，而这花费的成本则要比绝对的公平保证的低得多。所以，默认情况下 ReentrantLock 是“不公平”的，这一事实只是把同步中一直是事件的东西表面化而已。如果您在同步的时候并不介意这一点，那么在 ReentrantLock 时也不必为它担心。
以上两图与之前两图数据相同，只是添加了一个数据集，用来进行随机数基准检测，这次检测使用了公平锁，而不是默认的协商锁。正如您能看到的，公平是有代价的。如果您需要公平，就必须付出代价，但是请不要把它作为您的默认选择。
4）synchronized已无用？
虽然 ReentrantLock 是个非常动人的实现，相对 synchronized 来说，它有一些重要的优势，但是我认为急于把 synchronized 视若敝屣，绝对是个严重的错误。 java.util.concurrent.lock 中的锁定类是用于高级用户和高级情况的工具 。一般来说，除非您对 Lock 的某个高级特性有明确的需要，或者有明确的证据（而不是仅仅是怀疑）表明在特定情况下，同步已经成为可伸缩性的瓶颈，否则还是应当继续使用 synchronized。
为什么我在一个显然“更好的”实现的使用上主张保守呢？因为对于 java.util.concurrent.lock 中的锁定类来说，synchronized 仍然有一些优势。比如，在使用 synchronized 的时候，不可能忘记释放锁；在退出 synchronized 块时，JVM 会为您做这件事。您很容易忘记用 finally 块释放锁，这对程序非常有害。您的程序能够通过测试，但会在实际工作中出现死锁，那时会很难指出原因（这也是为什么根本不让初级开发人员使用 Lock 的一个好理由。）
另一个原因是因为，当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。 Lock 类只是普通的类，JVM 不知道具体哪个线程拥有 Lock 对象。而且，几乎每个开发人员都熟悉 synchronized，它可以在 JVM 的所有版本中工作。在 JDK 5.0 成为标准（从现在开始可能需要两年）之前，使用 Lock 类将意味着要利用的特性不是每个 JVM 都有的，而且不是每个开发人员都熟悉的。
5）什么时候选择用 ReentrantLock 代替 synchronized
既然如此，我们什么时候才应该使用 ReentrantLock 呢？答案非常简单 —— 在确实需要一些 synchronized 所没有的特性的时候，比如时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者轮询锁。ReentrantLock 还具有可伸缩性的好处，应当在高度争用的情况下使用它，但是请记住，大多数 synchronized 块几乎从来没有出现过争用，所以可以把高度争用放在一边。我建议用 synchronized 开发，直到确实证明 synchronized 不合适，而不要仅仅是假设如果使用 ReentrantLock “性能会更好”。请记住，这些是供高级用户使用的高级工具。（而且，真正的高级用户喜欢选择能够找到的最简单工具，直到他们认为简单的工具不适用为止。）。一如既往，首先要把事情做好，然后再考虑是不是有必要做得更快。