今年参加校招笔试面试经常遇到的一个问题。
总的来说，ReentrantLock并不是一种替代内置加锁的方法，而是当内置加锁机制不适用时，作为一种可选择的高级功能。与内置锁不同的是，Lock提供了一种无条件的、可轮询的、定时的以及可中断的锁获取操作，所有加锁和解锁的方法都是显式的。
实现机制
- Synchronized通过java对象头锁标记和Monitor对象实现
- Reentrantlock通过CAS、ASQ（AbstractQueuedSynchronizer）和locksupport（用于阻塞和解除阻塞）实现
- Synchronized依赖jvm内存模型保证包含共享变量的多线程内存可见性
- Reentrantlock通过ASQ的volatile state保证包含共享变量的多线程内存可见
可中断申请
如果使用synchronized申请一个内置锁时锁被其他线程持有, 那么当前线程将被挂起, 等待锁重新可用, 而且等待期间无法中断. 而显式锁提供了可中断申请: (B线程申请被A占有锁时，要等待，但可以用Thread.interrupt()中断)
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();
}
}
} 尝试型申请
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);
}
} 锁的释放(非块结构的加锁)
- 对于内置锁, 只要代码运行到同步代码块之外,就会自动释放锁,开发者无需担心抛出异常, 方法返回等情况发生时锁会没有被释放的问题.
- 然而对于显式锁,必须调用unlock方法才能释放锁.此时需要开发者自己处理抛出异常, 方法返回等情况.
- 通常会在finally代码块中进行锁的释放,还需注意只有申请到锁之后才需要释放锁, 释放未持有的锁可能会抛出未检查异常.
- 所以使用内置锁更容易一些, 而显式锁则繁琐很多.
- 但是显式锁释放方式的繁琐也带来一个方便的地方:锁的申请和释放不必在同一个代码块中.
唤醒和等待
- 线程可以wait在内置锁上,也可以通过调用内置锁的notify或notifyAll方法唤醒在其上等待的线程.
- 但是如果有多个线程在内置锁上wait,我们无法精确唤醒其中某个特定的线程.显式锁也可以用于唤醒和等待.调用Lock.newCondition方法可以获得Condition对象, 调用Condition.await方法将使得线程等待,调用Condition.singal或Condition.singalAll方法可以唤醒在该Condition对象上等待的线程. 由于同一个显式锁可以派生出多个Condition对象,因此我们可以实现精确唤醒.
- 通过ReentrantLock(boolean fair)构造函数创建ReentranLock锁时可以 为其指定公平策略,默认情况下为不公平锁.
- 多个线程申请公平锁时,申请时间早的线程优先获得锁(队列).然而不公平锁则允许插队,当某个线程申请锁时如果锁恰好可用,则该线程直接获得锁而不用排队.
- 比如线程B申请某个不公平锁时该锁正在由线程A持有, 线程B将被挂起. 当线程A释放锁时, 线程B将从挂起状态中恢复并打算再次申请(这个过程需要一定时间，导致没非公平的好). 如果此时恰好线程C也来申请锁,则不公平策略允许线程C立刻获得锁并开始运行.
- 内置锁采用不公平策略,而显式锁则可以指定是否使用不公平策略.
- 非公平锁能提高吞吐率
唤醒和等待
- 线程可以wait在内置锁上,也可以通过调用内置锁的notify或notifyAll方法唤醒在其上等待的线程.
- 但是如果有多个线程在内置锁上wait,我们无法精确唤醒其中某个特定的线程.显式锁也可以用于唤醒和等待.调用Lock.newCondition方法可以获得Condition对象, 调用Condition.await方法将使得线程等待,调用Condition.singal或Condition.singalAll方法可以唤醒在该Condition对象上等待的线程. 由于同一个显式锁可以派生出多个Condition对象,因此我们可以实现精确唤醒.
synchronized要被淘汰了？no
与显式锁相比，内置锁仍然有很大优势:
- 内置锁为许多开发人员熟悉，并且简洁紧凑，而且在许多现有的程序中都已经使用了内置锁
- ReentrantLock危险性大，如果忘记unlock，后果不堪设想
- ReentrantLock的非块结构特性仍然意味着，获取锁的操作不能与特定的栈帧关联起来，而内置锁可以
- synchronized是JVM的内置属性，它能执行一些优化(锁消除等)