AQS使用的设计模式 -模板方法模式

AQS 采用了标准的模版方法设计模式，对外提供的是以下的方法：

 // 独占模式
    public final void acquire(int arg);
    public final boolean release(int arg);
    // 独占可中断
    public final void acquireInterruptibly(int arg)
            throws InterruptedException;
    // 独占带超时时间的
    public final boolean tryAcquireNanos(int arg, long nanosTimeout);

    // 共享模式
    public final void acquireShared(int arg);
    public final boolean releaseShared(int arg);
    // 共享可中断
    public final void acquireSharedInterruptibly(int arg)
            throws InterruptedException;
    // 共享带超时时间
    public final boolean tryAcquireSharedNanos(int arg, long nanosTimeout) throws InterruptedException;

这些方法上都带了 final 关键字，也就是说不允许重写，那么哪些方法可以重写呢？

//独占模式
protected boolean tryAcquire(int arg);
protected boolean tryRelease(int arg);

//共享模式
protected int tryAcquireShared(int arg);
protected boolean tryReleaseShared(int arg);

//是否是独占模式
protected boolean isHeldExclusively()；

这些模版方法在代码中起什么作用呢？请看他们的调用方，在 acquire 方法中，当 tryAcquire 返回 true 则表示已经获得了锁，否则先 addWaiter 进入等待队列，再 acquireQueued 等候获取锁。acquireInterruptibly 也是类似的，区别只是对中断的处理不同。

  public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }
    public final void acquireInterruptibly(int arg)
            throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        if (!tryAcquire(arg))
            doAcquireInterruptibly(arg);
    }

以 acquire 为例，真正的排队阻塞等待锁是在 addWaiter 和 acquireQueued 中，那么 tryAcquire 方法需要做什么事儿呢？我们先看一下 ReentrantLock 中公平锁 FairSync 和非公平锁 NonfairSync 的实现：

// 公平锁
    static final class FairSync extends Sync {
        // omit a lot
        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;
        }
    }
    // 非公平锁
    static final class NonfairSync extends Sync {
        // omit a lot
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }
    abstract static class Sync extends AbstractQueuedSynchronizer {
        // omit a lot
        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            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;
        }
}

公平锁的 tryAcquire 方法所做事情大致如下：

检查了锁的状态，如果锁不被任何线程占用，且没有等待中的线程，则尝试用 CAS 设置状态，成功则 setExclusiveOwnerThread 设置占用锁的线程为当前线程。
如果当前线程已经占有了该锁，则 setState 更新更新重入次数。
上述两条都失败，则表示无法立即获得锁，返回 false。

非公平锁的 tryAcquire 也大致一样，只是缺少判断是否有等待中的线程，而是尽最大努力去获取锁。他们的共同点是更新锁状态 state，设置当前占用锁的线程 setExclusiveOwnerThread，其中最关键的是更新锁状态 state。

值得注意的是，为何 tryAcquire 这些方法不是抽象方法，而是提供了一个默认的抛异常的方法呢？因为 AQS 中包含多种模式，而实际使用者一般只需要一种，如果不提供默认拒绝的实现，那就需要使用方去手动覆盖，反而显得啰嗦了。

  // in AQS
    protected boolean tryAcquire(int arg) {
        throw new UnsupportedOperationException();
    }
    protected int tryAcquireShared(int arg) {
        throw new UnsupportedOperationException();
    }