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

前面我们已经了解过了加锁过程，下面就来看看解锁的过程是怎样的

这里提一下，公平锁和非公平锁的解锁过程是一样的

unlock方法

解锁调用的就是unlock方法

可以看到其调用的还是内部类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;
            //从队列后面开始遍历，找到最先被挂起的线程！
            //为什么要从后面遍历？
            for (Node t = tail; t != null && t != node; t = t.prev)
                //如果遍历到的线程状态小于0，代表线程被挂起
                if (t.waitStatus <= 0)
                    //s去记录被挂起的线程
                    s = t;
        }
        //最终如果可以找到最先被挂起的线程
        if (s != null)
            //让其重新启动
            LockSupport.unpark(s.thread);
    }

步骤如下

• 判断上一个执行完成的结点的waitStatus状态
  • 如果waitStatus状态小于0，代表上一个线程是被挂起了
  • 所以将waitStatus状态改回0（这一步是关联上线程抢锁时的CAS操作）
• 接下来，唤醒后面的线程，其实是去获取最先的一个未被取消的线程
  • 一般这个线程就是头结点的下一个
  • 但也有可能头结点的下一个被取消了
    • 此时就要进行遍历，从尾进行遍历整个队列，去找到最先的一个被挂起的线程（不包括新插入进来正在尝试获取锁的线程，也就是状态为0）
• 接下来，让最先的一个未被取消的线程重新启动

这里这样做的原因是，前面提到过，在线程去抢锁的过程中，CAS第一次时，会认为前面的一个线程被挂起了，将前面线程的waitStatus改为-1，CAS第二次，如果前面的线程仍然为-1，代表前面的线程仍然被挂起（只有在前面的线程释放锁的时候，才会改变waitStatus为0），所以自己也会挂起

所以，个人认为：如果一个线程执行太久了，后面的线程都被是有可能都被挂起的，那么就需要一个一个去唤醒他，就完全变成了一个重量级锁