CLH 隊列
CLH同步隊列是一個FIFO雙向隊列，AQS 依賴它來完成同步狀態的管理，當前線程如果獲取同步狀態失敗時，AQS則會將當前線程已經等待狀態等信息構造成一個節點（Node）並將其加入到CLH同步隊列，同時會阻塞當前線程，當同步狀態釋放時，會把首節點喚醒（公平鎖），使其再次嘗試獲取同步狀態。
在CLH同步隊列中，一個節點表示一個線程，它保存着線程的引用（thread）、狀態（waitStatus）、前驅節點（prev）、后繼節點（next）
CAS
如果使用synchronized關鍵字保證同步的，這會導致有鎖，鎖機制存在以下問題：
（1）在多線程競爭下，加鎖、釋放鎖會導致比較多的上下文切換和調度延時，引起性能問題。
（2）一個線程持有鎖會導致其它所有需要此鎖的線程掛起。
（3）如果一個優先級高的線程等待一個優先級低的線程釋放鎖會導致優先級倒置，引起性能風險。
volatile是不錯的機制，但是volatile不能保證原子性。因此對於同步最終還是要回到鎖機制上來。
獨占鎖是一種悲觀鎖，synchronized就是一種獨占鎖，會導致其它所有需要鎖的線程掛起，等待持有鎖的線程釋放鎖。
而另一個更加有效的鎖就是樂觀鎖。所謂樂觀鎖就是，每次不加鎖而是假設沒有沖突而去完成某項操作，如果因為沖突失敗就重試，直到成功為止。樂觀鎖用到的機制就是 CAS，Compare and Set。
CAS 操作包含三個操作數 —— 內存位置（V）、預期原值（A）和新值(B)。 如果內存位置的值與預期原值相匹配，那么處理器會自動將該位置值更新為新值 。否則，處理器不做任何操作。無論哪種情況，它都會在 CAS 指令之前返回該 位置的值。（在 CAS 的一些特殊情況下將僅返回 CAS 是否成功，而不提取當前 值。）CAS 有效地說明了“我認為位置 V 應該包含值 A；如果包含該值，則將 B 放到這個位置；否則，不要更改該位置，只告訴我這個位置現在的值即可。”
CAS雖然很高效的解決原子操作，但是CAS仍然存在三大問題。ABA問題，循環時間長開銷大和只能保證一個共享變量的原子操作ABA問題
因為CAS需要在操作值的時候檢查下值有沒有發生變化，如果沒有發生變化則更新，但是如果一個值原來是A，變成了B，又變成了A，那么使用CAS進行檢查時會發現它的值沒有發生變化，但是實際上卻變化了。ABA問題的解決思路就是使用版本號version。在變量前面追加上版本號，每次變量更新的時候把版本號加1，那么 A－B－A 對應的 version 就會變成 1－2－3。
從Java1.5開始JDK的atomic包里提供了一個類AtomicStampedReference來解決ABA問題。這個類的compareAndSet方法作用是首先檢查當前引用是否等於預期引用，並且當前標志是否等於預期標志，如果全部相等，則以原子方式將該引用和該標志的值設置為給定的更新值。
循環時間長開銷大
自旋CAS如果長時間不成功，會給CPU帶來非常大的執行開銷。如果JVM能支持處理器提供的pause指令那么效率會有一定的提升，pause指令有兩個作用：
第一它可以延遲流水線執行指令，使CPU不會消耗過多的執行資源，延遲的時間取決於具體實現的版本，在一些處理器上延遲時間是零。
第二它可以避免在退出循環的時候因內存順序沖突而引起CPU流水線被清空，從而提高CPU的執行效率。
只能保證一個共享變量的原子操作
當對一個共享變量執行操作時，我們可以使用循環CAS的方式來保證原子操作，但是對多個共享變量操作時，循環CAS就無法保證操作的原子性，這個時候就可以用鎖，或者有一個取巧的辦法，就是把多個共享變量合並成一個共享變量來操作。比如有兩個共享變量 i＝2，j=a，合並一下 ij=2a，然后用CAS來操作 ij。從Java1.5開始 JDK 提供了 AtomicReference類 來保證引用對象之間的原子性，你可以把多個變量放在一個對象里來進行CAS操作。
AQS
ReentrantLock；而談到
ReentrantLock，不得不談 AbstractQueuedSynchronized（AQS），類如其名，
抽象的隊列式的同步器，AQS定義了一套多線程訪問共享資源的同步器框架，許多同步類實現都依賴於它，如常用的 ReentrantLock/Semaphore/CountDownLatch...。我們以 ReentrantLock 作為講解切入點。
AbstractQueuedSynchronizer通過構造一個基於阻塞的CLH隊列容納所有的阻塞線程，而對該隊列的操作均通過Lock-Free（CAS）操作，但對已經獲得鎖的線程而言，ReentrantLock實現了偏向鎖的功能。
synchronized的底層也是一個基於CAS操作的等待隊列，但JVM實現的更精細，把等待隊列分為ContentionList和EntryList，目的是為了降低線程的出列速度；當然也實現了偏向鎖，從數據結構來說二者設計沒有本質區別。但synchronized還實現了自旋鎖，並針對不同的系統和硬件體系進行了優化，而Lock則完全依靠系統阻塞掛起等待線程。
當然Lock比synchronized更適合在應用層擴展，可以繼承AbstractQueuedSynchronizer定義各種實現，比如實現讀寫鎖（ReadWriteLock），公平或不公平鎖；同時，Lock對應的Condition也比wait/notify要方便的多、靈活的多。這里有一道筆試題：模擬一個容器，有 2 個線程生成數據寫入，10 個線程消費的生產者消費者模型。具體可以參看我的另外一篇博文：模擬生產者消費者模型。