内置锁和显式锁的区别--JCIP C13读书笔记

[本文是我对Java Concurrency In Practice C13的归纳和总结.  转载请注明作者和出处,  如有谬误, 欢迎在评论中指正. ]

任何java对象都可以用作同步的锁, 为了便于区分, 将其称为内置锁.

JDK5.0引入了显式锁: Lock及其子类(如ReentrantLock, ReadWriteLock等). 

内置锁和显式锁的区别有:

 

1. 可中断申请

如果使用synchronized申请一个内置锁时锁被其他线程持有, 那么当前线程将被挂起, 等待锁重新可用, 而且等待期间无法中断. 而显式锁提供了可中断申请:   

public class InterruptedLock extends Thread {
	private static Lock lock = new ReentrantLock();

	@Override
	public void run() {
		try {
			// 可中断申请, 在申请锁的过程中如果当前线程被中断, 将抛出InterruptedException异常
			lock.lockInterruptibly();
		} catch (InterruptedException e) {
			System.out.println("interruption happened");
			return;
		}

		// 如果运行到这里, 说明已经申请到锁, 且没有发生异常
		try {
			System.out.println("run is holding the lock");
		} finally {
			lock.unlock();
		}
	}

	public static void main(String[] args) throws InterruptedException {
		try {
			lock.lock();
			System.out.println("main is holding the lock.");
			Thread thread = new InterruptedLock();
			thread.start();
			// 1s后中断thread线程, 该线程此时应该阻塞在lockInterruptibly方法上
			Thread.sleep(1000);
			// 中断thread线程将导致其抛出InterruptedException异常.
			thread.interrupt();
			Thread.sleep(1000);
		} finally {
			lock.unlock();
		}
	}
} 

 

2. 尝试型申请

Lock.tryLock和Lock.tryLock(long time, TimeUnit unit)方法用于尝试获取锁. 如果尝试没有成功, 则返回false, 否则返回true. 而内置锁则不提供这种特性, 一旦开始申请内置锁, 在申请成功之前, 线程无法中断, 申请也无法取消. Lock的尝试型申请通常用于实现时间限定的task:

public boolean transferMoney(Account fromAcct, Account toAcct, DollarAmount amount, long timeout, TimeUnit unit)
		throws InsufficientFundsException, InterruptedException {
	long fixedDelay = getFixedDelayComponentNanos(timeout, unit);
	long randMod = getRandomDelayModulusNanos(timeout, unit);
	// 截止时间
	long stopTime = System.nanoTime() + unit.toNanos(timeout);

	while (true) {
		if (fromAcct.lock.tryLock()) {
			try {
				if (toAcct.lock.tryLock()) {
					try {
						if (fromAcct.getBalance().compareTo(amount) < 0)
							throw new InsufficientFundsException();
						else {
							fromAcct.debit(amount);
							toAcct.credit(amount);
							return true;
						}
					} finally {
						// 成功申请到锁时才需要释放锁
						toAcct.lock.unlock();
					}
				}
			} finally {
				// 成功申请到锁时才需要释放锁
				fromAcct.lock.unlock();
			}
		}
		// 如果已经超过截止时间直接返回false, 说明转账没有成功. 否则进行下次尝试.
		if (System.nanoTime() < stopTime)
			return false;
		NANOSECONDS.sleep(fixedDelay + rnd.nextLong() % randMod);
	}
}

尝试型申请也是可中断的.

 

3. 锁的释放

对于内置锁, 只要代码运行到同步代码块之外, 就会自动释放锁, 开发者无需担心抛出异常, 方法返回等情况发生时锁会没有被释放的问题. 然而对于显式锁, 必须调用unlock方法才能释放锁. 此时需要开发者自己处理抛出异常, 方法返回等情况. 通常会在finally代码块中进行锁的释放, 还需注意只有申请到锁之后才需要释放锁, 释放未持有的锁可能会抛出未检查异常.

所以使用内置锁更容易一些, 而显式锁则繁琐很多. 但是显式锁释放方式的繁琐也带来一个方便的地方: 锁的申请和释放不必在同一个代码块中.

 

4. 公平锁

通过ReentrantLock(boolean fair)构造函数创建ReentranLock锁时可以为其指定公平策略, 默认情况下为不公平锁.

多个线程申请公平锁时, 申请时间早的线程优先获得锁. 然而不公平锁则允许插队, 当某个线程申请锁时如果锁恰好可用, 则该线程直接获得锁而不用排队. 比如线程B申请某个不公平锁时该锁正在由线程A持有, 线程B将被挂起. 当线程A释放锁时, 线程B将从挂起状态中恢复并打算再次申请(这个过程需要一定时间). 如果此时恰好线程C也来申请锁, 则不公平策略允许线程C立刻获得锁并开始运行. 假设线程C在很短的一段时间之后就释放了锁, 那么可能线程B还没有完成恢复的过程. 这样一来, 节省了线程C从挂起到恢复所需要的时间, 还没有耽误线程B的运行. 所以在锁竞争激烈时, 不公平策略可以提高程序吞吐量.

内置锁采用不公平策略, 而显式锁则可以指定是否使用不公平策略.

 

5. 唤醒和等待

线程可以wait在内置锁上, 也可以通过调用内置锁的notify或notifyAll方法唤醒在其上等待的线程. 但是如果有多个线程在内置锁上wait, 我们无法精确唤醒其中某个特定的线程.

显式锁也可以用于唤醒和等待. 调用Lock.newCondition方法可以获得Condition对象, 调用Condition.await方法将使得线程等待, 调用Condition.singal或Condition.singalAll方法可以唤醒在该Condition对象上等待的线程. 由于同一个显式锁可以派生出多个Condition对象, 因此我们可以实现精确唤醒. 具体的应用请参考我早期的一篇博文:http://coolxing.iteye.com/blog/1236696

 

锁优化

JDK5.0加入显式锁后, 开发者发现显式锁相比内置锁具有明显的性能优势, 再加上显式锁的诸多新特性, 很多文章和书籍都推荐使用显式锁代替内置锁. 然而JDK6.0对内置锁做了大量优化, 显式锁已经不具备明显的性能优势. 所以如果使用的是JDK6.0及之后的版本, 且没有使用到显式锁提供的新特性, 则没有必要刻意使用显式锁, 原因如下:

1. 内置锁是JVM的内置特性, 更容易进行优化.

2. 监控程序(如thread dump)对内置锁具有更好的支持. 

3. 大多数开发者更熟悉内置锁.

JDK6.0对内置锁所做的优化措施可以参见"深入理解java虚拟机"13.3节.