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有他的适用场景。