面试被问ReentrantLock的公平锁与非公平锁

关注Java后端技术栈

回复“面试”获取最新资料

面试被问ReentrantLock的公平锁与非公平锁的区别以及实现。
建议先阅读Java中的锁原理、锁优化、CAS、AQS,看这篇就对了!

案例

public class LockDemo {
    public static void main(String[] args) {
        Lock lock = new ReentrantLock();
        try {
            lock.lock();
            System.out.println("获得锁");
        } finally {
            lock.unlock();
            System.out.println("释放锁");
        }
    }
}

运行结果

面试被问ReentrantLock的公平锁与非公平锁_第1张图片

先看ReentrantLock的构造方法源码:

private final Sync sync;
public ReentrantLock() {
     sync = new NonfairSync();
}

所以,记住默认是非公平锁有在new 的时候参数为true的时候才变成了公平锁。

再看Sync是个什么东东

 abstract static class Sync extends AbstractQueuedSynchronizer {
 }

可以看出这个是继承于AQS的一个静态抽象内部类。有两个子类

面试被问ReentrantLock的公平锁与非公平锁_第2张图片

这两个类也就是我们所说的公平锁与非公平锁。

还可以通过手动设置公平锁与非公平锁

public ReentrantLock(boolean fair) {
     sync = fair ? new FairSync() : new NonfairSync();
}

FairSync公平锁

 static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {
            acquire(1);
        }
       //尝试直接获取锁,返回值是boolean,代表是否获取到锁
       //返回true:
        //1.没有线程在等待锁;
        //2.重入锁,线程本来就持有锁,也就可以理所当然可以直接获取
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                //关键点
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            //判断是有锁的线程是否为当前线程。
            //可重入就在这里体现的,同一个线程多次调用lock方法
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

hasQueuedPredecessors()判断队列是否还有别的线程在等待锁,没有的话就尝试获取lock 。

compareAndSetState(0, acquires)尝试获取锁

NonfairSync非公平锁

static final class NonfairSync extends Sync {
     private static final long serialVersionUID = 7316153563782823691L;

     /**
      * Performs lock.  Try immediate barge, backing up to normal
      * acquire on failure.
      */
     final void lock() {
         //不管AQS队列有没有等待的线程,直接开始抢
         if (compareAndSetState(0, 1))
             setExclusiveOwnerThread(Thread.currentThread());
         else
            acquire(1);
     }

     protected final boolean tryAcquire(int acquires) {
         return nonfairTryAcquire(acquires);
     }
 }

compareAndSetState(0, 1)首先用一个CAS操作,判断state是否是0(表示当前锁未被占用),如果是0则把它置为1,并且

setExclusiveOwnerThread(Thread.currentThread());

设置当前线程为该锁的独占线程,表示获取锁成功。当多个线程同时尝试占用同一个锁时,CAS操作只能保证一个线程操作成功,剩下的只能乖乖的去排队啦。

总结

公平锁和非公平锁只有两处不同:

  1. 非公平锁在调用 lock 后,首先就会调用 CAS 进行一次抢锁,如果这个时候恰巧锁没有被占用,那么直接就获取到锁返回了。

  2. 非公平锁在 CAS 失败后,和公平锁一样都会进入到 tryAcquire 方法,在 tryAcquire 方法中,如果发现锁这个时候被释放了(state == 0),非公平锁会直接 CAS 抢锁,但是公平锁会判断等待队列是否有线程处于等待状态,如果有则不去抢锁,乖乖排到后面。

公平锁和非公平锁就这两点区别,如果这两次 CAS 都不成功,那么后面非公平锁和公平锁是一样的,都要进入到阻塞队列等待唤醒。

相对来说,非公平锁会有更好的性能,因为它的吞吐量比较大。当然,非公平锁让获取锁的时间变得更加不确定,可能会导致在阻塞队列中的线程长期处于饥饿状态。
推荐阅读目前行业薪资原来是这样的...
据说程序员才能看懂的趣图
一次蚂蚁金服的辛酸面试历程
5 个刁钻的 String 面试题!

关注Java后端技术栈发送  干货  免费获取下面超500G的资料

你可能感兴趣的:(面试被问ReentrantLock的公平锁与非公平锁)