J.U.C CAS

     在JDK1.5以前，也就是J.U.C加入JDK以前，Java是依靠synchronized關鍵字(JVM底層提供)來維護協調對共享字段的訪問，保證對這些變量的獨佔訪問權，而且之後其餘線程忽的該鎖時，將能夠看到對這些變量進行的更改(可見性，互斥性)。

     鎖機制的問題：

•   鎖問題不可迴避的，就是上下文切換，加劇系統線程調度，引發性能問題；
•   不一致的得到多個鎖的順序，還可能引起死鎖；
•   若是一個線程試圖得到其餘線程已經具備的鎖時，那麼該線程將被阻塞，直到該鎖可用，期間它沒法進行其餘任何操做，試想對一組操做序列加鎖，也許在這些操做序列中就僅僅一步操做須要同步，而其他大部分操做均可以同時進行，不會發生競爭問題。一個粗粒度的上鎖策略，將嚴重的致使系統的吞吐量。
•    若是阻塞的線程是優先級高的任務，那麼可能形成很是很差的結果(線程的優先級倒置)；

    前篇中所涉及的關鍵字volatile，在此處也並不能勝任，由於它僅僅提供可見性原語，它並不提供互斥訪問，原子操做原語(對volatile修飾的int遞增操做)。獨佔鎖是一種悲觀鎖，synchronized就是一種獨佔鎖。

    

比較並交換(CAS)

      支持併發的第一個處理器提供原子的測試並設置操做。如今的處理器(Inter和Sparc)使用的最通用的方法是實現名爲比較並轉換或者CAS的原語。

      CAS操做包含三個操做數-內存位置(V),預期原值(A)和新值(B)。若是內存位置的值與預期原值相匹配，那麼處理器會自動將該位置值更新爲新值。不然，處理器不作任何操做。CAS有效的說明了"我認爲位置V應該包含值A；若是包含該值,則將B放在這個位置；不然，就不要更改該位置的值，只告訴我這個位置如今的值既可"。

 

lock-free , wait-free

      若是每一個線程在其線程任意延遲(或者甚至失敗)時都將持續進行操做，就能夠說該算法是wait-free的。與此造成對比的是，lock-free算法要求僅某個線程老是執行操做。(wait-free的另外一種定義是保證每一個線程在器有限的步驟中正確計算本身的操做，而無論其餘線程的操做，計時，交叉，速度)

      無阻塞算法被普遍的用在操做系統和JVM級別，進行諸如線程和進程的調度任務。雖然他們的實現比較複雜，但相對與鎖定的備選算法，他們有許多優勢：能夠避免優先級倒置和死鎖的發生，競爭比較便宜，協調發生在更細粒度級別，提升吞吐量，其定義：

                                                  一個線程的失敗或者掛起不該該影響其餘線程的失敗或掛起的算法

 

       上面說了一大堆CAS的好，最後也該客觀的評價一下CAS，固然它也有其缺點：

•     "ABA"問題。J.U.C中AtomicMarkableReference, AtomicStampedReference解決"ABA"能夠排上用場。
•     不停的循環重試知道成功，消耗大量CPU資源。Exponential Backoff。
•     在高度競爭的環境下，CAS性能反而比直接加鎖低，因此CAS有他的適用場景。