Java并发之ReentrantLock

        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);

        如果参数为 true表示为公平锁，为 fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。

        在 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 lock

        5）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 <boolean表达式>

        如果<boolean表达式>为true，则程序继续执行。

        如果为false，则程序抛出AssertionError，并终止执行。

        （2）assert <boolean表达式> : <错误信息表达式>

        如果<boolean表达式>为true，则程序继续执行。

        如果为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 “性能会更好”。请记住，这些是供高级用户使用的高级工具。（而且，真正的高级用户喜欢选择能够找到的最简单工具，直到他们认为简单的工具不适用为止。）。一如既往，首先要把事情做好，然后再考虑是不是有必要做得更快。