Java 中非公平锁与公平锁的区别

最近在阅读Java的并行框架，从Executor框架->各种锁实现（Synchronized、ReentrantLock、Sempare等）->AQS框架->LockSupport类->UnSafe类，折磨了我一大段时间，在这里用一个ReentrantLock类中的公平锁与非公平锁做个总结吧。

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() {

            //如果现在没有线程持有，则让当前线程运行

            if (compareAndSetState(0, 1))

                setExclusiveOwnerThread(Thread.currentThread());

            else

                //直接请求资源，如果有则运行，否则阻塞

                acquire(1);

        }

        protected final boolean tryAcquire( int acquires) {

            return nonfairTryAcquire(acquires);

        }

    }

    /**

     * Sync object for fair locks

     */

    static final class FairSync extends Sync {

        private static final long serialVersionUID = -3000897897090466540L;

        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) {

                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 ;

        }

    }

该方法会首先判断当前状态，如果c==0说明没有线程正在竞争该锁，如果不c !=0 说明有线程正拥有了该锁。

如果发现c==0，则通过CAS设置该状态值为acquires,acquires的初始调用值为1，每次线程重入该锁都会+1，每次unlock 都会-1，但为0时释放锁。如果CAS设置成功，则可以预计其他任何线程调用CAS都不会再成功，也就认为当前线程得到了该锁，也作为Running线 程，很显然这个Running线程并未进入等待队列。

如果c !=0 但发现自己已经拥有锁，只是简单地++acquires，并修改status值，但因为没有竞争，所以通过setStatus修改，而非CAS，也就是说这段代码实现了偏向锁的功能，并且实现的非常漂亮。

       

 public final boolean release ( int arg) {

        if (tryRelease(arg)) {

            Node h = head ;

            if (h != null && h. waitStatus != 0)

                unparkSuccessor(h);

            return true ;

        }

        return false ;

    }

   protected final boolean tryRelease( int releases) {

            int c = getState() - releases;

            if (Thread.currentThread() != getExclusiveOwnerThread())

                throw new IllegalMonitorStateException();

            boolean free = false ;

            if (c == 0) {

                free = true ;

                setExclusiveOwnerThread( null );

            }

            setState(c);

            return free;

        }

从无限循环的代码可以看出，并不是得到解锁的线程一定能获得锁，必须在第6行中调用tryAccquire重新竞争，因为锁是非公平的，有可能被新 加入的线程获得，从而导致刚被唤醒的线程再次被阻塞，这个细节充分体现了“非公平”的精髓。通过之后将要介绍的解锁机制会看到，第一个被解锁的线程就是 Head，因此p == head的判断基本都会成功。

至此可以看到，把tryAcquire方法延迟到子类中实现的做法非常精妙并具有极强的可扩展性，令人叹为观止！当然精妙的不是这个Templae设计模式，而是Doug Lea对锁结构的精心布局。