Java并发（六）：ReentrantLock的解锁过程

可以看到其调用的还是内部类sync的方法，而且可以看到这是一个无返回值的方法

并且传入了一个为1的参数

release方法

可以看到，其调用的是AQS里面的release方法

步骤如下

• 先调用tryRelease方法，尝试进行解锁

• 然后判断是否需要唤醒线程

• 返回true，代表释放锁成功

• tryRelease方法返回false，表表释放锁失败，返回false

tryRelease方法

可以看到这个方法是AQS里面的一个未实现的方法，实现这个方法有ReentrantLock与ReentrantReadWriteLock

所以，具体的实现肯定是ReentrantLock的

实现的源码如下所示

步骤如下

• 计算锁被释放后的新状态，记录在变量c

• 判断当前线程是不是拥有锁（如果拥有了锁，在AbstartOwnableSychronizer的exclusiveOwnerThread会记录，AOS是被AQS所继承的）

• 如果不拥有锁就会报错，因为锁并不是自己的，没有资格释放

• 定义一个free变量看是否锁的新状态是不是变成可被占用了（进入到这一步就证明了当前线程拥有锁）

• 判断新的状态是不是为0

• 如果是0，让free变量为true，并且将锁记录占用自己的线程为null

• 将锁的状态更新（这一步过后，其他线程就可以争夺锁了，因为ReentrantLock的状态已经变为了0）

• 返回free变量给上一层，告知上一层锁是否不被占用了

接下来我们返回到release方法

下面的判断是这样的

从上面可以看到，如果锁没被占用了，那么tryRelease方法就会返回True，那么就会进行下面的判断

• 先记录一下当前线程队列的头结点

• 判断头结点是否不为空，而且waitStatus状态是否不为0（0代表线程正常运行，-1代表被挂起）

• 如果头结点不为空，代表仍有线程在等待

• 如果头结点waitStatus不为0，那就代表后面的线程被挂起了或者取消了（这个操作是针对后面的那些线程等待时间过长，CAS超过了两次，全部进入了挂起状态）

• 所以，接下来的一步就是去唤醒被后面被挂起的线程（前面提到过，队列里面是不存放正在执行的线程的，只存放需要排队的线程，头结点是不放线程的，不过会记录上一个执行线程的状态，因为在获取锁的时候，是将要执行的线程为头结点，然后将头结点里面的thread改为了null，但waitStatus是还在的）

• 返回True

• 如果头结点为空，或者头结点状态为0

• 代表没有线程等待了

• 返回false

unparkSuccessor方法

这个方法是唤醒被挂起的头结点，并且还要去整理线程队列

这个方法也是AQS里面的

源码如下

private void unparkSuccessor(Node node) {

/*

• If status is negative (i.e., possibly needing signal) try

• to clear in anticipation of signalling. It is OK if this

• fails or if status is changed by waiting thread.

*/

//判断头结点的waitStatus状态

int ws = node.waitStatus;

//如果waitStatus小于0，

//代表上一个执行的线程起先是休眠的，然后是被唤醒执行的

if (ws < 0)

//让这个线程cas改变自己的waitStatus

compareAndSetWaitStatus(node, ws, 0);

/*

• Thread to unpark is held in successor, which is normally

• just the next node. But if cancelled or apparently null,

• traverse backwards from tail to find the actual

• non-cancelled successor.

*/

//此时就是唤醒后面的线程了

Node s = node.next;

//如果头结点的下一个结点为空

//或者头结点的下一个结点的waitStatus状态大于0（代表被线程被取消执行）

if (s == null || s.waitStatus > 0) {

s = null;

//从队列后面开始遍历，找到最先被挂起的线程！