[本文是我对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节.
相关文章
