锁是用来控制多个线程访问共享资源的方式,对共享资源加锁能够有效解决对资源的并发问题,比如在方法中或方法块中加synchronized关键字。在JDK5以后并发包中增加了Lock接口,用来实现锁功能。Lock提供了与Synchronized类似的同步功能,但是在使用时需要显示的获取和释放锁,故而Lock又称为“显示锁”,Synchronized则称“隐式锁”。Lock相对于Synchronized,增加了锁的可操作性、可中断性以及超时机制等等特性。
上一篇学习了AQS这个非常重要的组件,打下夯实基础,这篇就继续学习Lock锁。
Lock
Lock是一个接口,定义了锁的获取和释放的基本操作,Lock接口提供的synchronized关键字不具备的主要特性如下:
- 尝试非阻塞地获取锁:当前线程尝试获取锁,如果这一时刻没有其他线程获取到锁,则成功获取,并持有锁资源。
- 能被中断地获取锁:获取到锁的线程能够响应中断,当获取到锁的线程被中断时,中断异常将会被抛出,同时锁也会被释放。
- 超时获取锁:在指定的截止时间之前获取锁,如果截止时间到了仍未获取到锁,则返回。
Lock子类继承关系如下图:
Lock接口的主要实现类有ReentrantLock、ReadLock、WriteLock,而ReentrantLock主要是基于AQS来完成同步操作的,本文就来说说ReentrantLock。
ReentrantLock
ReentrantLock是基于AQS(AbstractQueuedSynchronized)来实现的,其很多方法都是基于AQS来实现的,这里也就不再赘述相关的方法。
阅读本文之前还需要了解几个概念:
- 可重入锁:指的是同一线程外层函数获得锁之后 ,内层递归函数仍然有获取该锁的代码。也就是同一线程可以获得多个锁。不然就会发生死锁问题。
- 可中断锁:在某些条件下可以响应中断的锁。在Java中,synchronized就不是可中断锁,而 Lock是可中断锁。
- 公平锁:尽量以请求锁的顺序来获取锁。比如,同时有多个线程在等待一个锁,当这个锁被释放时,等待时间最久的线程(最先请求的线程)会获得该锁。
- 非公平锁:无法保证锁的获取是按照线程请求锁的顺序进行的。有可能锁刚被释放,正好新来了个线程请求锁,这样后面等待的线程就不能获得锁。在极端情况下,可能导致某些线程一直无法获取锁。
源码分析
Sync
ReentrantLock中提供了一个Sync类重写了AQS的几个重要方法,并且基于Sync提供了FairSync和NonfairSync两个类。
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
通过构造函数可以看到,ReentrantLock默认使用的是非公平锁,我们也可以通过参数指定使用公平还是非公平锁。
下面来看继承自AQS的核心内部类Sync:
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
abstract void lock();
/**
* 执行不公平的tryLock。 tryAcquire是在子类中实现的,但都需要非公平地尝试trylock方法。
*/
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (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;
}
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
protected final boolean isHeldExclusively() {
// 虽然我们必须在所有者之前阅读状态,但我们不需要这样做来检查当前线程是否为所有者
return getExclusiveOwnerThread() == Thread.currentThread();
}
final ConditionObject newCondition() {
return new ConditionObject();
}
// 从外部类传递的方法
final Thread getOwner() {
return getState() == 0 ? null : getExclusiveOwnerThread();
}
final int getHoldCount() {
return isHeldExclusively() ? getState() : 0;
}
final boolean isLocked() {
return getState() != 0;
}
/**
* 从流中重构实例(即将其反序列化)。
*/
private void readObject(java.io.ObjectInputStream s)
throws java.io.IOException, ClassNotFoundException {
s.defaultReadObject();
setState(0); // 重置为解锁状态
}
}
Sync继承自AQS,提供了许多加锁和解锁的方法,而公平锁(FairSync)和非公平锁(NonfairSync)主要就是在加锁的逻辑控制这块稍有不同。来看源码:
/**
* 为公平锁定同步对象
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* 获取公平锁
* 1. 当前无锁,并且没有等待更久的线程的话,给当前线程上锁
* 2. 当前有锁,但是加锁的线程是当前线程,增加状态值
* 其他情况返回false
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
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;
}
}
/**
* 为非公平锁定同步对象
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
/**
* 获取非公平锁
* 1. 当前无锁,给当前线程上锁
* 2. 当前有锁,但是加锁的线程是当前线程,增加状态值
* 其他情况返回false
*/
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
对比代码可以看出,实现公平性的方式就是 hasQueuedPredecessors()
这个方法,它用来查询在同步队列中是否有等待获取锁的时间比当前线程更长的线程。来看其源码:
public final boolean hasQueuedPredecessors() {
//正确性取决于在tail和head.next被初始化之前,如果当前线程是队列中的第一个,则它是精确的。
Node t = tail; // 按照反向初始化顺序读取字段
Node h = head;
Node s;
//头和尾节点不相同,并且头节点的后继节点为空或者当前线程不是头节点的后继节点,条件满足时,才确定当前线程前有正在排队的线程
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
从源码中可以看出,就是查询当前线程在同步队列中的位置前是否有等待已久正在排队的线程。
lock()
接着来看lock()方法:
public void lock() {
sync.lock();
}
lock方法很简单,直接调用的AQS的lock方法。sync的lock方法会根据公平性选择不同的lock方法,上面我们看过了FairSync和NonfairSync类,再来重温一下它的方法。
//公平锁
final void lock() {
acquire(1);
}
//非公平锁
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
NonfairSync会判断当前是否有线程持有锁,如果没有,直接获得锁返回。不然会和公平锁一样去调AQS的acquire方法。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
首先会用tryAcquire方法来判断是否能够获取锁,这个方法也在FairSync和NonfairSync中进行了重写,上面已经说了tryAcquire两种锁的区别,这里不再赘述。
unlock()
public void unlock() {
sync.release(1);
}
和lock()方法一样,unlock()方法也是调用的AQS的release()方法,所以我们直接看tryRelease()的实现就行。因为该方法公平性和非公平性是一样的,所以直接看Sync里的tryRelease()方法。
protected final boolean tryRelease(int releases) {
int c = getState() - releases; //释放状态
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
方法很简单,先释放状态,再判断状态state是不是0,0的话意味着该线程所有的锁都释放了,返回true,唤醒Sync同步队列后续的线程来争夺锁资源。
举个例子
public class ReentrantLockTest {
private static Lock fairLock = new ReentrantLock2(true);
private static Lock unfairLock = new ReentrantLock2(false);
private static class ReentrantLock2 extends ReentrantLock {
public ReentrantLock2(boolean isFair){
super(isFair);
}
public Collection<Thread> getQueuedThreads(){
List<Thread> list = new ArrayList<Thread>(super.getQueuedThreads());
Collections.reverse(list);
return list;
}
}
private static class Job extends Thread{
private Lock lock;
public Job(Lock lock){
this.lock = lock;
}
public void run(){
for (int i = 0; i < 2; i++) {
lock.lock();
try {
Collection<Thread> threads = ((ReentrantLock2) lock).getQueuedThreads();
Thread.sleep(1000);
System.out.println("获取锁的当前线程[" + Thread.currentThread().getName() + "], 同步队列中的线程" + getThreadName(threads));
} catch (InterruptedException e) {
e.printStackTrace();
}finally {
lock.unlock();
}
}
}
}
private static String getThreadName(Collection<Thread> threads) {
StringBuilder sb = new StringBuilder();
if (threads != null)
for (Thread thread : threads)
sb.append(thread.getName()).append(",");
String waitingThreads = null;
if (sb.length() > 0)
waitingThreads = sb.substring(0, sb.length() - 1);
return waitingThreads;
}
private void testLock(Lock lock) {
for (int i = 0; i < 5; i++) {
Job job = new Job(lock);
job.setName("线程" + (i + 1));
job.start();
}
}
public static void main(String[] args) {
ReentrantLockTest test = new ReentrantLockTest();
test.testLock(fairLock);
// test.testLock(unfairLock);
}
}
运行公平锁的结果:
获取锁的当前线程[线程1], 同步队列中的线程null
获取锁的当前线程[线程5], 同步队列中的线程线程2,线程4,线程3,线程1
获取锁的当前线程[线程2], 同步队列中的线程线程4,线程3,线程1,线程5
获取锁的当前线程[线程4], 同步队列中的线程线程3,线程1,线程5,线程2
获取锁的当前线程[线程3], 同步队列中的线程线程1,线程5,线程2
获取锁的当前线程[线程1], 同步队列中的线程线程5,线程2,线程4,线程3
获取锁的当前线程[线程5], 同步队列中的线程线程2,线程4,线程3
获取锁的当前线程[线程2], 同步队列中的线程线程4,线程3
获取锁的当前线程[线程4], 同步队列中的线程线程3
获取锁的当前线程[线程3], 同步队列中的线程null
运行非公平锁的结果:
获取锁的当前线程[线程3], 同步队列中的线程线程4
获取锁的当前线程[线程4], 同步队列中的线程线程2,线程5,线程1
获取锁的当前线程[线程4], 同步队列中的线程线程2,线程5,线程1,线程3
获取锁的当前线程[线程2], 同步队列中的线程线程5,线程1,线程3
获取锁的当前线程[线程5], 同步队列中的线程线程1,线程3
获取锁的当前线程[线程5], 同步队列中的线程线程1,线程3,线程2
获取锁的当前线程[线程1], 同步队列中的线程线程3,线程2
获取锁的当前线程[线程1], 同步队列中的线程线程3,线程2
获取锁的当前线程[线程3], 同步队列中的线程线程2
获取锁的当前线程[线程2], 同步队列中的线程null
通过例子的运行结果,可以明显的看到公平锁和非公平锁在获取锁时的区别,公平锁每次都是从同步队列中的第一个节点获取到锁,而非公平锁出现了一个线程连续获取锁的情况。
为什么会出现线程连续获取锁的情况?回顾非公平锁的nonfairTryAcquire()
方法,当一个线程请求锁时,只要获取了同步状态即成功获取了锁。在这个前提下,刚释放锁的线程再次获取同步状态的几率会更大,使得其他线程只能在同步队列中等待。
虽然公平锁保证了锁获取按照FIFO的原则,但是随之带来的是大量的线程切换。而非公平锁虽然可能会造成某些线程很少机会获取到锁,但极少的线程切换,使得非公平锁在性能上要远远高于公平锁。