首先我们从源码中可以获知，ReentrantLock是一个同步器的实现，它具有同步器的一些特性，下面我们就讨论下eentrantLock重入锁 ，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调用
reentrantLock.lock时，线程被加入到AQS的等待队列中。 - 线程1调用
await方法被调用时，该线程从AQS中移除，对应操作是锁的释放。 - 接着马上被加入到
Condition的等待队列中，以为着该线程需要signal信号。 - 线程2，因为线程1释放锁的关系，被唤醒，并判断可以获取锁，于是线程2获取锁，并被加入到AQS的等待队列中。
- 线程2调用
signal方法，这个时候Condition的等待队列中只有线程1一个节点，于是它被取出来，并被加入到AQS的等待队列中。 注意，这个时候，线程1 并没有被唤醒。 signal方法执行完毕，线程2调用reentrantLock.unLock()方法，释放锁。这个时候因为AQS中只有线程1，于是，AQS释放锁后按从头到尾的顺序唤醒线程时，线程1被唤醒，于是线程1回复执行。- 直到释放所整个过程执行完毕。
可以看到，整个协作过程是靠结点在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的等待队列中，所以才会被唤醒。