您的位置: 首页  >  文章  >  ReentrantLock重入锁 ，Condition 线程协作类学习

ReentrantLock重入锁 ，Condition 线程协作类学习

分类: 文章 • 2025-04-30 14:53:52

首先我们从源码中可以获知，ReentrantLock是一个同步器的实现，它具有同步器的一些特性，下面我们就讨论下eentrantLock重入锁 ，Condition 线程协作的协同工作。

ReentrantLock重入锁 ，Condition 线程协作类学习

ReentrantLock重入锁 ，Condition 线程协作类学习

话不多说，看以下代码

/**
 * 
 */
package com.cai.Thread;


import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;


/**
 *@title:
 *@author:allencai
 *@date:2018-4-21上午9:57:35
 */
public class SignalThread {


/**
*@method:main
*@descript:TODO
*@author:allencai
*@return:void
*@date:2018-4-21上午9:57:35
*/
//创建重入锁
final static ReentrantLock reentrantLocklock=new ReentrantLock();
//static Condition newCondition;
public static void main(String[] args) {
Condition newCondition = reentrantLocklock.newCondition();
AccessThread accessThread=new AccessThread(newCondition);
accessThread.start();
SendThread sendThread = new SendThread(newCondition);
sendThread.start();


}
static class AccessThread extends Thread{
Condition newCondition;
public AccessThread(Condition newCondition){
this.newCondition=newCondition;
}
@Override
public void run() {
reentrantLocklock.lock();
try {
System.err.println("我要等待接受信号"+this);
newCondition.await();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.err.println("拿到一个信号"+this);
reentrantLocklock.unlock();
}
}
    static class SendThread extends Thread{
    Condition newCondition;
    public SendThread(Condition newCondition){
this.newCondition=newCondition;
}
@Override
public void run() {
reentrantLocklock.lock();
try {
System.err.println("我要发送接受信号"+this);
Thread.sleep(1000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
newCondition.signalAll();
System.err.println("发送一个信号"+this);
reentrantLocklock.unlock();
}
}


}

那我们就讨论下上述代码的实现原理：首先AccessThread 接受信号线程启动获取重入锁，获取执行权，然后输出我们的语句“等待信号”，当调用await方法时，封装我们的线程信息，同时将我们线程从AQS队列中移除，同时将其加入到condition队列，释放锁，此时循环AQS队列中线程，因为我们AQS队列只有SendThread线程，所以它获取到我们的锁，然后产生信号，休眠1秒钟，唤醒其他线程此时我们线程AccessThread从condition队列中加入到AQS队列中，当我们unlock时释放锁，我们AccessThread重新获得锁执行线程任务。详解如下：

首先还是要明白，reentrantLock.newCondition() 返回的是Condition的一个实现，该类在AbstractQueuedSynchronizer中被实现，叫做newCondition()

1
public Condition newCondition()   { return sync.newCondition(); }

它可以访问AbstractQueuedSynchronizer中的方法和其余内部类（AbstractQueuedSynchronizer是个抽象类，至于他怎么能访问，这里有个很奇妙的点，后面我专门用demo说明 ）

现在，我们一起来看下Condition类的实现，还是从上面的demo入手，

为了方便书写，我将AbstractQueuedSynchronizer缩写为AQS

当await被调用时，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
public final void await() throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();
    Node node = addConditionWaiter(); // 将当前线程包装下后，
                                      // 添加到Condition自己维护的一个链表中。
    int savedState = fullyRelease(node);// 释放当前线程占有的锁，从demo中看到，
                                        // 调用await前，当前线程是占有锁的
 
    int interruptMode = 0;
    while (!isOnSyncQueue(node)) {// 释放完毕后，遍历AQS的队列，看当前节点是否在队列中，
        // 不在 说明它还没有竞争锁的资格，所以继续将自己沉睡。
        // 直到它被加入到队列中，聪明的你可能猜到了，
        // 没有错，在singal的时候加入不就可以了？
        LockSupport.park(this);
        if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
            break;
    }
    // 被唤醒后，重新开始正式竞争锁，同样，如果竞争不到还是会将自己沉睡，等待唤醒重新开始竞争。
    if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
        interruptMode = REINTERRUPT;
    if (node.nextWaiter != null)
        unlinkCancelledWaiters();
    if (interruptMode != 0)
        reportInterruptAfterWait(interruptMode);
}

回到上面的demo，锁被释放后，线程1开始沉睡，这个时候线程因为线程1沉睡时，会唤醒AQS队列中的头结点，所所以线程2会开始竞争锁，并获取到，等待3秒后，线程2会调用signal方法，“发出”signal信号，signal方法如下：

1
2
3
4
5
6
7
8
public final void signal() {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    Node first = firstWaiter; // firstWaiter为condition自己维护的一个链表的头结点，
                              // 取出第一个节点后开始唤醒操作
    if (first != null)
        doSignal(first);
}

说明下，其实Condition内部维护了等待队列的头结点和尾节点，该队列的作用是存放等待signal信号的线程，该线程被封装为Node节点后存放于此。

1
2
3
4
5
6
public class ConditionObject implements Condition, java.io.Serializable {
    private static final long serialVersionUID = 1173984872572414699L;
    /** First node of condition queue. */
    private transient Node firstWaiter;
    /** Last node of condition queue. */
    private transient Node lastWaiter;

关键的就在于此，我们知道AQS自己维护的队列是当前等待资源的队列，AQS会在资源被释放后，依次唤醒队列中从前到后的所有节点，使他们对应的线程恢复执行。直到队列为空。

而Condition自己也维护了一个队列，该队列的作用是维护一个等待signal信号的队列，两个队列的作用是不同，事实上，每个线程也仅仅会同时存在以上两个队列中的一个，流程是这样的：

  1. 线程1调用reentrantLock.lock时，线程被加入到AQS的等待队列中。
  2. 线程1调用await方法被调用时，该线程从AQS中移除，对应操作是锁的释放。
  3. 接着马上被加入到Condition的等待队列中，以为着该线程需要signal信号。
  4. 线程2，因为线程1释放锁的关系，被唤醒，并判断可以获取锁，于是线程2获取锁，并被加入到AQS的等待队列中。
  5. 线程2调用signal方法，这个时候Condition的等待队列中只有线程1一个节点，于是它被取出来，并被加入到AQS的等待队列中。 注意，这个时候，线程1 并没有被唤醒。
  6. signal方法执行完毕，线程2调用reentrantLock.unLock()方法，释放锁。这个时候因为AQS中只有线程1，于是，AQS释放锁后按从头到尾的顺序唤醒线程时，线程1被唤醒，于是线程1回复执行。
  7. 直到释放所整个过程执行完毕。

可以看到，整个协作过程是靠结点在AQS的等待队列和Condition的等待队列中来回移动实现的，Condition作为一个条件类，很好的自己维护了一个等待信号的队列，并在适时的时候将结点加入到AQS的等待队列中来实现的唤醒操作。

看到这里，signal方法的代码应该不难理解了。

取出头结点，然后doSignal

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
public final void signal() {
    if (!isHeldExclusively()) {
        throw new IllegalMonitorStateException();
    }
    Node first = firstWaiter;
    if (first != null) {
        doSignal(first);
    }
}
 
private void doSignal(Node first) {
    do {
        if ((firstWaiter = first.nextWaiter) == null) // 修改头结点，完成旧头结点的移出工作
            lastWaiter = null;
        first.nextWaiter = null;
    } while (!transferForSignal(first) && // 将老的头结点，加入到AQS的等待队列中
             (first = firstWaiter) != null);
}
 
final boolean transferForSignal(Node node) {
    /*
     * If cannot change waitStatus, the node has been cancelled.
     */
    if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
        return false;
 
    /*
     * Splice onto queue and try to set waitStatus of predecessor to
     * indicate that thread is (probably) waiting. If cancelled or attempt
     * to set waitStatus fails, wake up to resync (in which case the
     * waitStatus can be transiently and harmlessly wrong).
     */
    Node p = enq(node);
    int ws = p.waitStatus;
    // 如果该结点的状态为cancel 或者修改waitStatus失败，则直接唤醒。
    if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
        LockSupport.unpark(node.thread);
    return true;
}

可以看到，正常情况 ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL)这个判断是不会为true的，所以，不会在这个时候唤醒该线程。

只有到发送signal信号的线程调用reentrantLock.unlock()后因为它已经被加到AQS的等待队列中，所以才会被唤醒。





相关推荐