ReentrantLock的公平锁与非公平锁的区别

在上一文中图示并发线程中的锁问题，介绍了“进度图确定锁的范围”。分析了从c语言角度使用信号量sem_t来实现锁的互斥。这次来介绍下java中可重入锁ReentrantLock的公平锁和非公平锁的概念。java在大型的电商应用，高并发编程中可谓占着很重要的位置。

分析UML图，我们发现ReentrantLock的lock和unlock等重要的方法都是由AbstractQueuedSynchronizer AQS同步队列器来实现的。网上对AQS源码细致分析的有很多，但这篇文章主要是想讲解公平锁与非公平锁的区别，所以打算删繁就简，将区别二者的核心代码拿出来对比：

公平锁

		final void lock() {
		//如果节点之前有前继节点，会进行入队
           	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();
            int c = getState();
            if (c == 0) { //在获取锁之前会判断当前节点之前是否有前驱节点，如果没有才会尝试CAS加锁
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    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;
        }

非公平锁

        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {//不会判断是否还有节点等待，直接进行CAS尝试加锁
                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;
        }

父类共有方法

    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

总结：
1.在新创建一个线程进行lock时，非公平锁会直接尝试CAS加锁，如果加锁成功就先执行。就像排队加塞一样，也由此得来不公平锁。而公平锁会先判断是否有线程节点等待，如果有只能乖乖的去等待。
2.在第一次CAS加锁失败后，进行acquire方法。会进行再一次尝试加锁tryAcquire。如果此时锁已经释放，那么非公平锁就会获取执行机会。但是公平锁只能老老实实的检查前面还有没有排队的人。

这就是公平锁和非公平锁的两个区别。从字面意思理解，非公平锁来了就想加塞执行。有两次加塞机会如果失败的话，后面的执行操作就像公平锁一样，老实的在等待队列中等着前一个线程节点唤醒它。

在没有公平性需求的前提下尽量使用非公平锁，因为公平锁每次都会上锁都会检查队列中是否有等待节点，会带来性能开销

参考链接：
https://juejin.cn/post/6844903661106102279
java并发之美

发现掘金上面的文章挺硬核的，又多了一个搜索博客的地点。