CAS实例：线程安全的读写队列

在并发环境下ArrayList和HashMap都是不安全的，对于ArrayList，假设多线程对同一个ArrayList一起做写入操作，有可能多个线程同时对ArrayList中同一个位置做赋值，导致最后期望数据和实际数据不一致。HashMap一样有可能出现数据不一致这个问题，且使用HashMap有可能出现更大的灾难，那就是多线程对同一个HashMap做遍历过程中可能会破坏链表的结构，出现如两个结点互相指向对方导致链表成环的问题，最后程序一直死循环无法退出。

解决的方法也有，例如用Vector代替ArrayList，用Collections.synchronizedMap（）方法包装HashMap或是使用专门为并发进行了优化的ConcurrentHashMap。Collections.synchronizedMap（）中使用了一个Map<K, V>接口，里面有一个final Object mutex的类实例对象来实现互斥操作，例如Map.get（）方法的实现是：

public V get(Object key) {

        synchronized (mutex) {

               return m.get(key);

        }

}

可以看到方法调用前会去获得mutex的对象锁。这样做保证了线程安全，但是锁操作保护临界资源，即同一时刻只能有一个线程能执行，其他需要获得这个锁的线程都会进行等待，对于追求高效率的多线程，这样做明显性能不太好。

      不用锁就可以让多线程长期保持执行状态，不会因为等待锁而导致线程等待，但是不用锁就要想其他办法来解决可能导致的数据不一致问题。为了保证多线程并发安全性，无锁的方式使用了一种复杂的算法-比较交换算法（CAS Compare And Swap）。

      抽象地表达CAS就是，这个算法需要三个参数，V,E和N。V表示要做更新的变量（例如对其做写入操作）；E表示变量的预期值，即你希望读到这个变量时它的预期值是什么；N表示变量的新值，仅当变量V的值等于预期值E时，才会对变量V的值设置未N，否则就什么也不做，最后返回当前V的值。

      多线程一起用CAS对临界资源的访问，各个线程执行前都会先去比较自己拿到的临界资源是否符合自己的“期望”，如果是才会执行自己的操作，如果不符合自己的期望值，例如被其他线程修改了，那么就不做操作，这样来保证数据的正确性或一致性。可以看出，这个期望值让当前线程可以发现某一变量是否被其他线程给修改过了（通过比较期望值），然后做出正确的处理。

      在JDK中有一个ConcurrentLinkedQueue类来实现线程安全的队列，采用链表的存储结构，这个队列就是CAS实例之一，例如它的增加结点方法就比较复杂，在看它的源码之前，我想先简单回顾回顾出现的两样东西：volatile关键字和Unsafe类。

      对于volatile修饰的变量，即