Java并发编程实战——AQS详解和ReentrantLock实现

最新推荐文章于 2023-04-27 11:19:45 发布

No_Game_No_Life_

最新推荐文章于 2023-04-27 11:19:45 发布

阅读量393

点赞数 2

分类专栏：并发编程面试准备

本文链接：https://blog.csdn.net/No_Game_No_Life_/article/details/104675432

版权

面试准备同时被 2 个专栏收录

42 篇文章 16 订阅

订阅专栏

并发编程

16 篇文章 0 订阅

订阅专栏

文章目录

引入
AQS核心思想
面试总结：什么是AQS
ReentrantLock实现方式

引入

从Lock的实现类ReentrantLock说起，查看源码时有一个很明显的特点是：基本上所有的方法的实现实际上都是调用了其静态内存类Sync中的方法，而Sync类继承了AbstractQueuedSynchronizer（AQS）。可以看出要想理解ReentrantLock关键核心在于对队列同步器AbstractQueuedSynchronizer（简称同步器）的理解。
在这里插入图片描述
AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。

AQS核心思想

AQS核心思想是：

如果请求的共享资源没有被占用（空闲状态），那么将当前线程设置为有效的工作线程，并且将共享资源设置为占用（锁定状态）。
如果共享资源被占用，那么就需要设定一套线程阻塞等待和唤醒后锁分配的机制。这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。

CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列（虚拟的双向队列即不存在队列实例，仅存在结点之间的关联关系）。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点（Node）来实现锁的分配。

AQS同步状态与共享/独占

AQS 使用一个int成员变量来表示同步状态，AQS 使用CAS对该同步状态进行原子操作实现对其值的修改，通过内置的FIFO队列来完成获取资源线程的排队工作。

private volatile int state;//共享变量，使用volatile修饰保证线程可见性

//返回同步状态的当前值
protected final int getState() {  
        return state;
}
 // 设置同步状态的值
protected final void setState(int newState) { 
        state = newState;
}
//原子地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

AQS定义两种资源共享方式

Exclusive（独占）：只有一个线程能执行，如ReentrantLock。又可分为公平锁和非公平锁：
- 公平锁：按照线程在队列中的排队顺序，先到者先拿到锁
- 非公平锁：当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的
Share（共享）：多个线程可同时执行，如Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 。

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等)，AQS已经在上层已经帮我们实现好了：通过SupportLock的park和unpark来做阻塞和唤醒；通过CAS来释放、锁定锁资源，比如compareAndSetWaitStatus(通过unsafe来完成)。

AQS是实现锁（也可以是任意同步组件）的关键。可以这样理解二者的关系：锁是面向使用者，它定义了使用者与锁交互的接口，隐藏了实现细节；AQS是面向锁的实现者，它简化了锁的实现方式，屏蔽了同步状态的管理，线程的排队，等待和唤醒等底层操作。

AQS的模板方法设计模式

AQS的设计是使用模板方法设计模式，它将一些方法开放给子类进行重写，而同步器给同步组件所提供模板方法又会重新调用被子类所重写的方法。
AQS使用了模板方法模式，自定义同步器时需要重写下面几个AQS提供的模板方法：

isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)//独占方式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)//独占方式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
tryReleaseShared(int)//共享方式。尝试释放资源，成功则返回true，失败则返回false。

一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。但AQS也支持自定义同步器同时实现独占和共享两种方式，如ReentrantReadWriteLock。

以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0(即释放锁)为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的(state会累加)，这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

这就是使用AQS的方式可以归纳总结为这么几点：

同步组件（这里不仅仅值锁，还包括CountDownLatch等）的实现依赖于同步器AQS，在同步组件实现中，使用AQS的方式被推荐定义继承AQS的静态内存类；
AQS采用模板方法进行设计，AQS的protected修饰的方法需要由继承AQS的子类进行重写实现，当调用AQS的子类的方法时就会调用被重写的方法；
AQS负责同步状态的管理，线程的排队，等待和唤醒这些底层操作，而Lock等同步组件主要专注于实现同步语义；
在重写AQS的方式时，使用AQS提供的getState(),setState(),compareAndSetState()方法进行修改同步状态

同步组件通过AQS实现的一个例子

首先，我们展示一下AQS需要重写的方法：
在这里插入图片描述
再展示一下模版方法：

下面使用一个例子来进一步理解下AQS的使用。这个例子也是来源于AQS源码中的example。

class Mutex implements Lock, java.io.Serializable {
    // Our internal helper class
    // 继承AQS的静态内存类
    // 重写方法
    private static class Sync extends AbstractQueuedSynchronizer {
        // Reports whether in locked state
        protected boolean isHeldExclusively() {
            return getState() == 1;
        }

        // Acquires the lock if state is zero
        public boolean tryAcquire(int acquires) {
            assert acquires == 1; // Otherwise unused
            if (compareAndSetState(0, 1)) {
                setExclusiveOwnerThread(Thread.currentThread());
                return true;
            }
            return false;
        }

        // Releases the lock by setting state to zero
        protected boolean tryRelease(int releases) {
            assert releases == 1; // Otherwise unused
            if (getState() == 0) throw new IllegalMonitorStateException();
            setExclusiveOwnerThread(null);
            setState(0);
            return true;
        }

        // Provides a Condition
        Condition newCondition() {
            return new ConditionObject();
        }

        // Deserializes properly
        private void readObject(ObjectInputStream s)
                throws IOException, ClassNotFoundException {
            s.defaultReadObject();
            setState(0); // reset to unlocked state
        }
    }

    // The sync object does all the hard work. We just forward to it.
    private final Sync sync = new Sync();
    //使用同步器的模板方法实现自己的同步语义
    public void lock() {
        sync.acquire(1);
    }

    public boolean tryLock() {
        return sync.tryAcquire(1);
    }

    public void unlock() {
        sync.release(1);
    }

    public Condition newCondition() {
        return sync.newCondition();
    }

    public boolean isLocked() {
        return sync.isHeldExclusively();
    }

    public boolean hasQueuedThreads() {
        return sync.hasQueuedThreads();
    }

    public void lockInterruptibly() throws InterruptedException {
        sync.acquireInterruptibly(1);
    }

    public boolean tryLock(long timeout, TimeUnit unit)
            throws InterruptedException {
        return sync.tryAcquireNanos(1, unit.toNanos(timeout));
    }
}

MutexDemo：

public class MutextDemo {
    private static Mutex mutex = new Mutex();

    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            Thread thread = new Thread(() -> {
                mutex.lock();
                try {
                    Thread.sleep(3000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    mutex.unlock();
                }
            });
            thread.start();
        }
    }
}

执行情况：
在这里插入图片描述

上面的这个例子实现了独占锁的语义，在同一个时刻只允许一个线程占有锁。MutexDemo新建了10个线程，分别睡眠3s。从执行情况也可以看出来当前Thread-6正在执行占有锁而其他Thread-7,Thread-8等线程处于WAIT状态。按照推荐的方式，Mutex定义了一个继承AQS的静态内部类Sync,并且重写了AQS的tryAcquire等等方法，而对state的更新也是利用了setState(),getState()，compareAndSetState()这三个方法。在实现实现lock接口中的方法也只是调用了AQS提供的模板方法（因为Sync继承AQS）。从这个例子就可以很清楚的看出来，在同步组件的实现上主要是利用了AQS，而AQS“屏蔽”了同步状态的修改，线程排队等底层实现，通过AQS的模板方法可以很方便的给同步组件的实现者进行调用。而针对用户来说，只需要调用同步组件提供的方法来实现并发编程即可。同时在新建一个同步组件时需要把握的两个关键点是：

实现同步组件时推荐定义继承AQS的静态内存类，并重写需要的protected修饰的方法；
同步组件语义的实现依赖于AQS的模板方法，而AQS模板方法又依赖于被AQS的子类所重写的方法。

通俗点说，因为AQS整体设计思路采用模板方法设计模式，同步组件以及AQS的功能实际上别切分成各自的两部分：

同步组件实现者的角度：

通过可重写的方法：

独占式： tryAcquire()(独占式获取同步状态），tryRelease()（独占式释放同步状态）；
共享式：tryAcquireShared()(共享式获取同步状态)，tryReleaseShared()(共享式释放同步状态)；

通过上述方法告诉AQS怎样判断当前同步状态是否成功获取或者是否成功释放。同步组件专注于对当前同步状态的逻辑判断，从而实现自己的同步语义。这句话比较抽象，举例来说，上面的Mutex例子中通过tryAcquire方法实现自己的同步语义，在该方法中如果当前同步状态为0（即该同步组件没被任何线程获取），当前线程可以获取同时将状态更改为1返回true，否则，该组件已经被线程占用返回false。很显然，该同步组件只能在同一时刻被线程占用，Mutex专注于获取释放的逻辑来实现自己想要表达的同步语义。

AQS的角度

而对AQS来说，只需要同步组件返回的true和false即可，因为AQS会对true和false会有不同的操作，true会认为当前线程获取同步组件成功直接返回，而false的话就AQS也会将当前线程插入同步队列等一系列的方法。

总的来说，同步组件通过重写AQS的方法实现自己想要表达的同步语义，而AQS只需要同步组件表达的true和false即可，AQS会针对true和false不同的情况做不同的处理，至于底层实现，不多做介绍了。

面试总结：什么是AQS

AQS是用来构建锁和一些同步组建的框架，它采用模版方法模式：将一些方法开放给子类进行重写，同时AQS本身的final方法会调用被子类重写后的方法，（这样就实现了模版方法模式）。

AQS实现的核心思想是：

如果请求的共享资源没有被占用（空闲状态），那么将当前线程设置为有效的工作线程，并且将共享资源设置为占用（锁定状态）。
比如，AQS提供的模版方法分为独占和共享（资源）两种方式，这两种方式都是通过一个volatile修饰的int类型的变量来表示同步状态，并且通过Unsafe的CAS方法来修改同步状态的值，比如共享资源的方法里负数表示没有资源了，而正数表示还剩余资源。
如果共享资源被占用，那么就需要设定一套线程阻塞等待和唤醒后锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中。
AQS中维护了一个FIFO队列（CLH），用于记录等待的线程，上锁和释放锁的过程可以认为是线程入队列和出队列的过程；获取不到锁，入队列等待；出队列时被唤醒。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点(Node)来实现锁的分配。

ReentrantLock实现方式

AQS中有一个表示状态的字段state，ReentrantLock用它表示线程重入锁的次数，Semaphore用它表示剩余的许可数量，FutureTask用它表示任务的状态。对state变量值的更新都采用CAS操作保证更新操作的原子性。

ReentrantLock总共有三个内部类，并且三个内部类是紧密相关的，下面先看三个类的关系。
在这里插入图片描述

ReentrantLock类的sync非常重要，对ReentrantLock类的操作大部分都直接转化为对Sync和AbstractQueuedSynchronizer类的操作。
由于Sync继承了AQS，所以基本上都可以转化为对AQS的操作。

NonfairSync执行lock的第一步就是尝试通过compareAndSetState(0, 1)获取锁；而FairSync不会进行此操作。

NonfairSync通过nonfairTryAcquire获取锁；
FairSync通过tryAcquire获取锁。这两个方法的主要逻辑相同，唯一的差别在于FairSync在获取锁前会先检查FIFO队列中是否有Node存在，如果没有，则当前线程执行compareAndSetState(0, 1)操作，尝试获取锁。

	// 非公平锁
	static final class NonfairSync extends Sync {
	    // 版本号
	    private static final long serialVersionUID = 7316153563782823691L;
	
	    // 获得锁
	    final void lock() {
	        if (compareAndSetState(0, 1)) // 比较并设置状态成功，状态0表示锁没有被占用
	            // 把当前线程设置独占了锁
	            setExclusiveOwnerThread(Thread.currentThread());
	        else // 锁已经被占用，或者set失败
	            // 以独占模式获取对象，忽略中断
	            acquire(1); //AQS final 方法，acquire会调用下面的tryAcquire()
	    }
	
	    protected final boolean tryAcquire(int acquires) {
	        return nonfairTryAcquire(acquires);
	    }
    
		final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);//AQS final 方法
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {//AQS final 方法
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);//AQS final 方法
                return true;
            }
            return false;
        }
	}

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

        final void lock() {
            acquire(1);//AQS final 方法，acquire会调用下面的tryAcquire()
        }

        /**
         * 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)) {//AQS final 方法
                    setExclusiveOwnerThread(current);//AQS final 方法
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {//AQS final 方法
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

其实现很简单，就重写了state的增加的逻辑而已。再来看看AQS的acquire方法：

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

由于Java是从左向右执行的，当tryAcquire返回false的时候，即抢占锁失败的时候，会执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg))，即将当前线程包装到Node中。

    private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

然后执行selfInterrupt()，中断当前线程：

    static void selfInterrupt() {
        Thread.currentThread().interrupt();
    }

可以看出

Fair只要资源被其他线程占用，该线程就会添加到sync queue中的尾部，而不会先尝试获取资源。
Nonfair每一次都会尝试去获取资源，如果此时该资源恰好被释放，则会被当前线程获取，这就造成了不公平的现象，当获取不成功，再加入队列尾部。