一文彻底弄懂并发包中的读写锁实现原理

628 阅读3分钟

导读

这篇文章我们来ReentrantLock中的Condition实现原理。阅读完本篇文章,你将了解到:

1、Condition底层是如何实现的


有如下的ReentrantLock和Condition:

// 锁和条件变量
private final Lock lock = new ReentrantLock();
// 条件
private final Condition condition1 = lock.newCondition();

下面来看看执行await和signal的流程。

1、await等待

一般地,只有线程获取到lock之后,才可以使用condition的await方法。假设此时线程1获取到了ReentrantLock锁,在执行代码逻辑的时候,发现某些条件不符合,于是调用了以下代码:

while(xxx条件不满足) {
  condition1.await();
}

此时AQS主要执行以下动作:

  1. 线程1把自己包装成节点,waitStatus设为CONDITION(-2),追加到ConditionObject中的条件队列(每个ConditionObject有一个自己的条件队列);
  2. 线程1释放锁,把state设置为0;
  3. 然后唤醒等待队列中head节点的下一个节点;

如下:

image-20200314121818770

接下来进入一个循环,如果判断到当前线程的节点不在等待队列,那么会一直让当前线程阻塞,代码如下:

while (!isOnSyncQueue(node)) {
  LockSupport.park(this);
  if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
    break;
}

这个时候已经唤醒其他线程继续处理了,只有其他线程执行了condition1.signal或者condition1.signalAll之后,才会唤醒线程1进行处理后续的流程。

2、signal唤醒

当另一个线程执行了 condition1.signal之后,主要是做了以下事情:

  1. 把条件队列中的第一个节点追加到等待队列中;
  2. 把等待队列原来尾节点的waitStatus设置为SIGNAL。

image-20200314144725065

然后继续处理自己的事情,自己的事情处理完成之后,会释放锁,唤醒等待队列中head节点的下一个节点线程进行工作。

3、await恢复后继续执行

被唤醒的如果是之前执行了await方法的线程,那么该线程会接着就像往await方法里面阻塞处的下面继续执行,下面是源码:

// 如果当前节点不在等待队列,会一直进行阻塞
while (!isOnSyncQueue(node)) {
  LockSupport.park(this);
  if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
    break;
}
// 该方法主要做以下事情:
// 1.尝试获取ReentrantLock锁
// 2.获取成功,把现在线程节点变为新的head节点
// 3. 否则根据继续休眠等待
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
  interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // 如果等待节点被取消了,那么从条件队列中移除
  unlinkCancelledWaiters();
if (interruptMode != 0)
  reportInterruptAfterWait(interruptMode);

可以发现,这里主要是判断到当前线程节点已经放入等待队列了,那么会尝试获取锁,获取成功则继续往下执行代码。

第一节我们知道只有线程获取到ReentrantLock的锁之后才可以继续往下执行,中间可能会因为执行await而进入条件队列并释放锁,最后又会被唤醒重新获取锁,继续往下执行。最后按照书写规范,我们一定会在代码中执行ReentrantLock.unlock()释放锁,然后继续唤醒等待队列后续线程继续执行。

本文作者:arthinking

博客链接:

ReentrantLock的Condition原理解析

版权声明:版权归作者所有,未经许可不得转载,侵权必究!联系作者请加公众号。