1.是什么？
全稱：AbstractQueuedSynchronizer
抽象的隊列式的同步器，AQS定義了一套多線程訪問共享資源的同步器框架，許多同步類實現(xiàn)都依賴于它，如常用的ReentrantLock/Semaphore/CountDownLatch...
2.框架
數(shù)據(jù)結構：
? ? ? 1）維護了一個volatile int state
? ? ? 2）先進先出的雙向鏈表，頭節(jié)點為獲取鎖的線程
自定義同步器和AQS
? ? ? AQS頂層已經(jīng)實現(xiàn)了等待隊列的維護（出隊／入隊）
? ? ? 自定義同步器只需要實現(xiàn)共享資源state的獲取和釋放，自定義同步器主要需要實現(xiàn)的方法包括：
? ? ? ? ? 1）isHeldExclusively()：該線程是否正在獨占資源。只有用到condition才需要去實現(xiàn)它。
? ? 2） tryAcquire(int)：獨占方式。嘗試獲取資源，成功則返回true，失敗則返回false。
? 3） tryRelease(int)：獨占方式。嘗試釋放資源，成功則返回true，失敗則返回false。
? ? 4）tryAcquireShared(int)：共享方式。嘗試獲取資源。負數(shù)表示失敗；0表示成功，但沒有剩余可用資源；正數(shù)表示成功，且有剩余資源。
? ? 5）tryReleaseShared(int)：共享方式。嘗試釋放資源，如果釋放后允許喚醒后續(xù)等待結點返回true，否則返回false。
舉例說明：
RetreentLock：state初始化為0，表示未鎖定狀態(tài)。A線程lock()時，會調用tryAcquire()獨占該鎖并將state+1。此后，其他線程再tryAcquire()時就會失敗，直到A線程unlock()到state=0（即釋放鎖）為止，其它線程才有機會獲取該鎖。當然，釋放鎖之前，A線程自己是可以重復獲取此鎖的（state會累加），這就是可重入的概念。但要注意，獲取多少次就要釋放多么次，這樣才能保證state是能回到零態(tài)的。
? ? ? ? CountDownLatch:任務分為N個子線程去執(zhí)行，state也初始化為N（注意N要與線程個數(shù)一致）。這N個子線程是并行執(zhí)行的，每個子線程執(zhí)行完后countDown()一次，state會CAS減1。等到所有子線程都執(zhí)行完后(即state=0)，會unpark()主調用線程，然后主調用線程就會從await()函數(shù)返回，繼續(xù)后余動作。
? ? ? ? 思考：unpark()之后，應該是重新競爭CPU的執(zhí)行權吧？
3.源碼分析
? 按照acquire-release、acquireShared-releaseShared的次序分析AQS頂層源碼
? 3.1 AbstractQueuedSynchronizer#acquire(int i)
? ? ? ? 分析：此方法是獨占模式下線程獲取共享資源的頂層入口。如果獲取到資源，線程直接返回，否則進入等待隊列，直到獲取到資源為止，且整個過程忽略中斷的影響。這也正是lock()的語義，當然不僅僅只限于lock()。獲取到資源后，線程就可以去執(zhí)行其臨界區(qū)代碼了。
? ? ? ? ? AbstractQueuedSynchronizer#tryAcquire()具體資源的獲取交由自定義同步器去實現(xiàn)了（通過state的get/set/CAS），至于能不能重入，能不能加塞，那就看具體的自定義同步器怎么去設計了，自定義同步器在進行資源訪問時要考慮線程安全的影響。
? ? ? ? ? ? 思考：為什么不事先為抽象？
這里之所以沒有定義成abstract，是因為獨占模式下只用實現(xiàn)tryAcquire-tryRelease，而共享模式下只用實現(xiàn)tryAcquireShared-tryReleaseShared。如果都定義成abstract，那么每個模式也要去實現(xiàn)另一模式下的接口。說到底，Doug Lea還是站在咱們開發(fā)者的角度，盡量減少不必要的工作量。
? AbstractQueuedSynchronizer#addWaiter(Node mode)，首先以指定的模式構造節(jié)點（共享還是獨占），再嘗試以cas的方式插入隊尾，失敗再使用enq方法插入隊尾。
此處對Node進行解釋：
? ? Node結點是對每一個訪問同步代碼的線程的封裝，其包含了需要同步的線程本身以及線程的狀態(tài)。變量waitStatus則表示當前被封裝成Node結點的等待狀態(tài)：
CANCELLED：值為1，在同步隊列中等待的線程等待超時或被中斷，需要從同步隊列中取消該Node的結點，其結點的waitStatus為CANCELLED，即結束狀態(tài)，進入該狀態(tài)后的結點將不會再變化。
SIGNAL：值為-1，被標識為該等待喚醒狀態(tài)的后繼結點，當其前繼結點的線程釋放了同步鎖或被取消，將會通知該后繼結點的線程執(zhí)行。說白了，就是處于喚醒狀態(tài)，只要前繼結點釋放鎖，就會通知標識為SIGNAL狀態(tài)的后繼結點的線程執(zhí)行。
CONDITION：值為-2，與Condition相關，該標識的結點處于等待隊列中，結點的線程等待在Condition上，當其他線程調用了Condition的signal()方法后，CONDITION狀態(tài)的結點將從等待隊列轉移到同步隊列中，等待獲取同步鎖。
PROPAGATE：值為-3，與共享模式相關，在共享模式中，該狀態(tài)標識結點的線程處于可運行狀態(tài)。
0狀態(tài)：值為0，代表初始化狀態(tài)。
AbstractQueuedSynchronizer#enq(Node node)，通過自旋的方式設置頭節(jié)點或者尾節(jié)點。
AbstractQueuedSynchronizer#acquireQueued(Node node)，該線程獲取資源失敗，已經(jīng)被放入等待隊列尾部了。
? ? ? ? ? 分析：1)如果前驅節(jié)點是頭節(jié)點，則自旋的方式獲取共享資源
? ? ? ? ? ? ? ? ? ? 2）否則進入park當前線程waiting，等待被unpark
安全點：
? ? ? 是否應該park需要根據(jù)AbstractQueuedSynchronizer#shouldParkAfterFailedAcquire(Node pred, Node node)方法判斷，該方法會尋找一個安全點，然后再將當前線程掛起。
? ? ? ? 步驟分析：
? ? ? ? ? ? ? 前置節(jié)點的waitStatus是否為SIGNAL，如果是，則直接掛起；如果不是，繼續(xù)回溯，直到找到SIGNAL狀態(tài)的節(jié)點或者找到一個waitStatus的節(jié)點并CAS的設置為SIGNAL狀態(tài)。
*****? 釋放獨占鎖
*****? 獲取共享鎖
*****? 釋放共享鎖
*********************************
readwritelock的實現(xiàn)方式：
