JAVA并发编程学习17（AQS学习）

AQS是Java并发包中的抽象类AbstractQueuedSynchronizer的简称，其整体的架构架构设计如下图：

ReentrantLock

对于ReentrantLock来说，其执行逻辑如下所示：

1.尝试获取对象的锁，如果获取不到（意味着已经有其它线程持有了锁，并且尚未释放），那么它（当前线程）就会进入到AQS的阻塞队列当中。

2.如果获取到，那么根据锁是公平锁还是非公平锁来进行不同处理：

        2-1.如果是公平锁，那么线程会被直接放置到AQS阻塞队列的末尾

        2-2.如果是非公平锁，那么线程会首先尝试进行CAS计算，如果成功，则直接获取到锁；如果失败，则与公平锁的处理方式一致，当前线程会被放置到阻塞队列末尾。

3.当锁被释放时（调用了unlock方法），那么底层会调用release方法对state成员变量的值进行减一操作，如果减一后，state的值不为0，那么release操作就执行完毕；如果减一操作后，state的值为0，则调用LockSupport的unpark方法唤醒该线程后的等待队列中的第一个后继线程（底层通过pthread_mutex_unlock指令），将其唤醒，使之能够获取到对象的锁（release时，对于公平锁与非公平锁的处理逻辑是一致的）；之所以调用release方法后state的值可能不为零，其原因在于ReentrantLock是可重入锁，表示线程可以多次调用lock方法，导致每调用一次，state的值都会加一。

对于ReentrantLock来说，所谓的上锁，本质上就是对AQS中的state成员变量的操作：对该成员变量+1，表示上锁；对该成员变量-1，表示释放锁。

ReentrantReadWriteLock

关于ReentrantReadWriteLock的操作逻辑：

读锁：

1.在获取读锁时，会尝试判断当前对象是否拥有了写锁，如果已经拥有，则直接失败；

2.如果没有写锁，就表示当前对象没有排它锁，则当前线程会尝试给对象加锁；

3.如果当前线程已经持有了该对象的锁，那么直接将读锁的数量加1.

写锁：

1.在获取写锁时，会尝试判断当前对象是否拥有了锁（读锁与写锁），如果已经拥有锁且持有锁的线程并非当前线程，则直接失败。

2.如果当前对象没有被加锁，那么写锁就会为当前对象上锁，并且将写锁的个数加1；

3.将当前对象的排它锁线程持有者设置为自己。

关于AQS与synchronized关键字之间的关系：

synchronized

1.synchronized关键字在底层的C++实现中，存在两个重要的数据结构（集合）：WaitSet，EntryList

2.WaitSet中存放的是调用了Object的wait方法的线程对象（被封装成了C++的Node对象）

3.EntryList中存放的是陷入到阻塞状态、需要获取monitor的那些线程对象

4.当一个线程被notify后，它就会从WaitSet中移动到EntryList中

5.进入到EntryList以后，该线程依然需要与其他线程争抢monitor对象

6.如果争抢到了，就表示该线程获取到了对象的锁，它就可以以排他方式执行对应的同步代码。

AQS

1.AQS中存在两种队列，分别是Condition对象上的条件队列，以及AQS本身的阻塞队列

2.这两个队列中的每一个对象都是Node实例（里面封装了线程对象）

3.当位于Condition条件队列中的线程被其他线程signal以后，该线程就会从条件队列中移动到AQS的阻塞队列中

4.位于AQS阻塞队列中的Node对象本质上都是由一个双向链表来构成的

5.在获取AQS锁时，这些进入到阻塞队列中的线程会按照在队列中的排序先后尝试获取（之所说尝试获取，是因为AQS分为公平锁和非公平锁）。

6.当AQS阻塞队列中的线程获取到锁后，就表示该线程已经可以正常执行了

7.陷入到阻塞状态的线程，依然需要进入到操作系统的内核态，进入阻塞（通过park方法实现）