JUC
java.util.concurrent包，
这个包是从JDK1.5开始引入的，在此之前，这个包独立存在着，它是由Doug Lea开发的，名字叫backport-util-concurrent，
在1.5开始引入java，命名路径为java.util.concurrent，其中的基本实现方式，也有所改变。
（来源于一位大牛的blog： 深入浅出Java Concurreny （http://www.blogjava.net/xylz/archive/2010/06/30/324915.html））
下图表明，java.util.concurrent包主要有，
AtomicI原子化，基于原子操作的循环CAS算法。
Collections容器，ConcurrentLinkedQueue（非阻塞队列—基于原子引用的循环CAS）
Locks锁，基于非阻塞队列的循环CAS + JNI的unsafe.park(false, 0L)阻塞线程
Collections容器的ConcurrentHashMap是，基于ReentrantLock的锁分段技术
Collections容器的阻塞队列是，基于ReentrantLock / Condition的锁等待技术
Executor线程池。
CAS
CAS，compare and swap，比较和替换
（也有人直接理解为compare and set，其实是一样的）。
CAS是一种乐观锁做法，而且整个JUC的实现都是基于CAS机制的。
如果直接用synchronized加锁，这是一种悲观锁做法，所谓悲观锁，就是悲观的认为线程是绝对不安全的，必须保证在swap值之前，没有任何其它线程操作当前值。
synchronized是一种独占锁，性能受限于这种悲观策略。这一点将在后面详述。
而CAS是一种乐观锁机制，所谓乐观锁，就是相信在compare 和swap之间，被其它线程影响的可能性不大，只要compare校验通过，就可以进行swap。
在Java中，compareAndSet的基本代码如下：
1 public final boolean compareAndSet(int expect, int update) { 2 return unsafe.compareAndSwapInt(this, valueOffset, expect, update); 3 }
从代码中看，java的compareAndSet使用使用JNI中的unsafe接口来实现的，
这是因为，现代CPU基本都提供了特殊的指令，能够做到自动更新共享数据的同时，检测其它线程的干扰，也就是说，CPU本身提供了compareAndSet功能。
所以才能提供JNI的CAS接口。
有了JNI的CAS接口，基于该接口的JUC就能获得更高性能。
在 Intel 处理器中，比较并交换通过指令cmpxchg实现。比较是否和给定的数值一致，如果一致则修改，不一致则不修改。
