【锁】ReentrantLock之获取锁时公平性的体现与锁的释放

文章首发于：clawhub.club

---

公平锁实现了先进先出的公平性，但是由于来一个线程就加入队列中，往往都需要阻塞，再由阻塞变为运行，这种上下文切换非常资源。
非公平锁由于允许插队，所以上下文切换少，能保证的大的吞吐量，但是容易出现饥饿问题。

查看ReentrantLock源码，其内部有三个重要的内部类：
Sync继承自AbstractQueueSynchronizer同步器，这个锁的同步操作由这个Sync来保证。
NofairSync非公平同步器，继承Sync,在同步的基础上，保证线程获取锁是非公平的。
FairSync公平同步器，继承Sync,公平锁的体现。

ReentrantLock默认初始化为非公平锁。

在执行ReentrantLock的Lock方法的时候，会调用Sync的Lock方法，最后由NofairSync或者FairSync实现。

   public void lock() {
        sync.lock();
    }
  /**
         * Performs {@link Lock#lock}. The main reason for subclassing
         * is to allow fast path for nonfair version.
         */
        abstract void lock();

首先看NonfairSync

 /**
         * Performs lock.  Try immediate barge, backing up to normal
         * acquire on failure.
         * 执行获取锁的操作，尝试获取锁，如果失败的话，进入同步队列等待。
         */
        final void lock() {
            //CAS尝试获取锁。
            if (compareAndSetState(0, 1))
                //如果获取锁成功的话，将自己放在当前持有锁的线程位置。
                setExclusiveOwnerThread(Thread.currentThread());
            else
                //获取锁失败，直接入同步队列，这块就和公平锁一样了。
                acquire(1);
        }

非公平锁在执行获取锁操作的时候，会先尝试的获取一下锁，即和同步队列中等待的线程竞争，如果获取失败的时候才会入同步队列，
这步操作即减少了入队、阻塞、出队的操作，能增大锁处理的吞吐量，但是也有可能同步队列中的等待线程迟迟不能获取到锁，因为都被新来的抢占了，发生饥饿现象。
源码中，当前获取锁失败之后会调用AQS中定义的acquire方法，最后又会回调本类中的tryAcquire(int acquires)方法：

  /**
         * 由父类回调，尝试获取锁
         * @param acquires
         * @return
         */
        protected final boolean tryAcquire(int acquires) {
            //非公平方式获取
            return nonfairTryAcquire(acquires);
        }

而nonfairTryAcquire方法的逻辑功能因为ReentrantLock的tryLock()方法与非公平同步器都需要使用，所以提到Sync中实现：

   /**
         * Performs non-fair tryLock.  tryAcquire is implemented in
         * subclasses, but both need nonfair try for trylock method.
         * 执行非公共方式获取锁，按理说应该子类实现，但是ReentrantLock的tryLock()方法也需要这块的逻辑，所以提到了上层处理。
         */
        final boolean nonfairTryAcquire(int acquires) {
            //获取当前线程
            final Thread current = Thread.currentThread();
            //获取当前锁状态
            int c = getState();
            //如果锁状态为0，即没有线程持有当前锁
            if (c == 0) {
                //尝试获取锁，次数为重入次数
                if (compareAndSetState(0, acquires)) {
                    //设置线程位
                    setExclusiveOwnerThread(current);
                    return true;
                }
                //有线程持有当前的锁，确认一下是不是自己获取的，如果是，就重入，减少了再次获取锁的开销
            } else if (current == getExclusiveOwnerThread()) {
                //锁重入次数更新
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                //直接更新，因为已经获取了锁，所以不会有竞争
                setState(nextc);
                return true;
            }
            return false;
        }

这段代码中就体现了ReentrantLock的可重入性，在当前线程再次获取锁的时候，发现获取失败了，而且当前持有锁的线程正是自己，
那就将锁的重入次数增加，减少了再次获取锁的消耗。

再来看FairSync

  /**
         * 获取锁
         */
        final void lock() {
            //直接调用AQS的方法，最后会回调tryAcquire方法
            acquire(1);
        }

        /**
         * Fair version of tryAcquire.  Don't grant access unless
         * recursive call or no waiters or is first.
         * 公平版本的获取锁，
         */
        protected final boolean tryAcquire(int acquires) {
            //获取当前线程
            final Thread current = Thread.currentThread();
            //获取当前锁的状态，即AQS中的state属性
            int c = getState();
            //c==0即锁没有被占用
            if (c == 0) {

                //首先检查自己是不是处于头节点的后继节点，即队列中有没有排在我前面的节点
                //之后将state设置为1
                if (!hasQueuedPredecessors() &&
                        compareAndSetState(0, acquires)) {
                    //上面两步都成功之后,将AbstractOwnableSynchronizer的exclusiveOwnerThread设置为当前线程，就此获取锁成功。
                    setExclusiveOwnerThread(current);
                    //获取锁成功
                    return true;
                }
            }
            //如果当前的线程持有这个锁
            else if (current == getExclusiveOwnerThread()) {
                //记录锁重入次数
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            //获取锁失败
            return false;
        }

源码中，没有了非公平锁的一进来就和同步队列中的等待线程竞争，而是直接进入同步队列，接下来就是AQS的问题了，以前分析过就不写了。

直接将锁的释放也分析一下：

/**
         * 释放锁执行操作，因为想要释放锁，肯定是持有锁，所以此方法内部不需要同步方法。
         * @param releases 释放次数
         * @return
         */
        protected final boolean tryRelease(int releases) {
            //获取释放后当前锁被重入次数
            int c = getState() - releases;
            //为什么还要判断一下当前线程是不是获取锁的线程呢？
            //可能是：如果有线程没有调用Lock但是先效用Unlock的时候，做一个判断。
            //为什么不把这句判断放到  int c = getState() - releases; 之前呢，即减少一次锁重入次数的计算？
            // 不知道为啥。。欢迎有想法的小伙伴给我些提示
           if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();

           //设置个锁标志位
            boolean free = false;
            //只有当c为0时，此锁才不被线程持有
            if (c == 0) {
                free = true;
                //清掉线程位
                setExclusiveOwnerThread(null);
            }
            //设置锁状态
            setState(c);
            return free;
        }

这里面有两个疑问，目前只能瞎猜。