java并发包中aqs浅谈

aqs原理

aqs即AbstractQueuedSynchronizer，是java并发包中的一个抽象类，ReentrantLock,Semaphore,CountdownLatch均基于该类实现自己的功能。
aqs内部维护了一个状态变量state，state=0表示aqs的锁可以被获取，state>0则告知线程需要等待(对于共享模式，需要满足state>n，n表示可共享的量，比如信号量的个数)。所有的等待线程构成一个双端队列sync，这些线程的等待和唤醒有unsafe包中的park和unpark方法完成。aqs运作的简单过程如下

1. 尝试获取锁，如果state>0则无法获取锁，通过cas操作进入sync队列；
如果state=0，cas修改state的状态，成功则表示获得锁，失败则进入sync队列
2. 释放锁，cas修改state状态，唤醒sync队列中头结点的下一个可用节点去争夺锁，
如果是共享模式下的锁，被唤醒的节点获得锁后将继续传递唤醒操作

ReentrantLock（非共享）

对于可重入锁，在获得锁的条件下是可以继续获得锁的，这时候state增加，而释放锁则必须要等到和获得相同次数的释放操作才会真正释放锁，即state=0。
对于可重入锁的条件，其内部维护一个条件等待队列，当条件执行signal操作时，会将条件等待队列中的线程加入到sync队列中竞争锁。如果是signalAll则是将所有线程加入到sync队列。
对于公平锁，实质是尝试获得锁的线程当且仅当state=0并且sync队列中没有线程进行等待时在获得锁，否则进入等待队列。

Semaphore和CountdownLatch（共享）

信号量初始化时会指定state的值为n，即允许多少次获得锁，每获取一次state减1，当state为n时，执行获取操作的线程将被阻塞，当有线程释放信号时会唤醒等待线程，等待线程如果获得信号会继续传播唤醒操作。
对于闭锁同样初始化state为n，当且仅当state为0时等待闭锁的线程可以突破闭锁，否则在sync队列中等待

结尾

额，aqs中需要竞争的地方均使用cas操作，没有使用syncronized
参考：https://segmentfault.com/a/1190000008471362