谈谈AQS

AQS是什么？

　　AQS全称叫AbstractQueuedSynchronizer，顾名思义，抽象的队列同步装置，在java中是一个抽象类。java JUC包下常用的同步类都是通过继承AQS实现的，那么AQS到底是怎么实现的呢，

又为什么说AQS=volatile+CAS,我们通过分析ReentrantLock类的源码来一步步解开谜底。

　　我们从初始化ReentrantLock开始

 /**
     * Creates an instance of {@code ReentrantLock}.
     * This is equivalent to using {@code ReentrantLock(false)}.
     */
    public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

　　可以看到ReentrantLock有两个构造方法，看带参数的注释可以知道如果传true，则是公平锁，这里我们使用无参构造，所以我们走的是上面一个构造方法。

所以我们调用的就是NonfairSync（非公平锁）的lock方法，如下图：

/**
     * Sync object for non-fair locks
     */
    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);
        }
    }

首先来分析compareAndSetState方法到底干了啥，进入该方法；

protected final boolean compareAndSetState(int expect, int update) {
        // See below for intrinsics setup to support this
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }

其实从名字上我们也可以看出这个是一个典型的CAS操作，看到unsafe就没必要往下看了，因为unsafe里面的方法被java设计者封装了，我们是看不了的。

可以看到这里是想对stateOffset这个属性进行CAS操作，找到stateOffset，发现最终指向的是state属性，

再找到state属性：

发现该属性是通过volatile修饰的一个int值，暂时我们还不知道这个属性有什么作用。再回到lock方法

假设我们是第一个线程第一次进行锁操作，那么这期间肯定没其他线程会去修改state的值，则肯定会更新成功，此时该方法返回true，并将state设置为1。

返回true之后就会执行setExclusiveOwnerThread方法，该方法表示将当前线程设置为独占访问。此时，第一个线程加锁的步骤就完了，然后就执行业务

代码，执行完再调用onlock方法解锁。当然这不是我们关注的重点，我们的重点是，当有第二个，第三个线程调用lock方法的时候，我们该怎么去保证同步。

继续回到代码，当第二给线程调用lock方法的时候，假设此时第一个线程还没有释放锁，那么一定会进入else的acquire方法：

先来看tryAcquire()这个方法，顾名思义，尝试去获得锁，tryAcquire实际调用的是nonfairTryAcquire() 方法，因为我们看的非公平锁。

代码如下：

这个方法比较简单，如果state等于0也就是没拿到锁，就用cas去尝试拿，拿到就返回true，如果

在当前线程中，如果说当前线程和锁的所有者是同一个线程，则把sate+1，表示锁的重入。

再来看acquireQueued(addWaiter(Node.EXCLUSIVE), arg)，这个方法就不去细看了，大致 的意思

就是通过cas实现往队列里面放入等待的线程，当执行的线程释放锁的时候，该队列的线程会相互竞争

直到某一个线程拿到锁。

总结：

1. 调用自定义同步器的tryAcquire()尝试直接去获取资源，如果成功则直接返回；
2. 没成功，则addWaiter()将该线程加入等待队列的尾部，并标记为独占模式；
3. acquireQueued()使线程在等待队列中休息，有机会时（轮到自己，会被unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
4. 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。

由于此函数是重中之重，我再用流程图总结一下：

至此，acquire()的流程终于算是告一段落了。这也就是ReentrantLock.lock()的流程，不信你去看其lock()源码吧，整个函数就是一条acquire(1)！！！

参考：https://www.cnblogs.com/waterystone/p/4920797.html（如果需要详细的了解aqs的源码实现，请看这篇文章）