一、Java多线程 -- JUC包源码分析1 -- CAS/乐观锁
乐观锁其实就是不加锁，用CAS + 循环重试，实现多个线程/多个客户端，并发修改数据的问题
使用AtomicStampedReference类下的
public boolean compareAndSet(V expectedReference, //旧值 V newReference, //新值 int expectedStamp, //旧版本号 int newStamp //新版本号)
方法可实现原子性的CAS
–上面的atomicRef.compareAndSet（..）的第一个参数，传入的是一个ReferenceIntegerPair对象，它里面包含了2个字段：值 + 版本号。这也就意味着，它同时比较了值和版本号。
– 值不等，则肯定被其他线程改过了，不用再比较版本号，cas提交失败；
值相等，再比较版本号，如果版本号也相等，则说明真的没有被改过，cas提交成功；
值相等，版本号不等，则就是出现了ABA，cas提交失败。
二、Java多线程 -- JUC包源码分析2 -- Copy On Write/CopyOnWriteArrayList/CopyOnWriteArraySet
CopyOnWrite,
顾名思义：就是在Write的时候，不直接Write源数据，而是把数据Copy一份出来改，改完之后，再通过悲观锁或者乐观锁的方式写回去。
CopyOnWrite的主要目的是实现“写”加锁，“读”不加锁，从而提高并发度。在上面例子中，CopyOnWriteArrayList使用了CopyOnWrite + 悲观锁； NumberRange使用了CopyOnWrite + 乐观锁。
CopyOnWriteArraySet就是用Array实现的一个Set，保证所有元素都不重复。其内部就是封装的一个CopyOnWriteArrayList
三、Java多线程 -- JUC包源码分析3-- volatile/final语义
-volatile应用1 – 内存可见性 – JMM内存模型
线程A，线程B有各自的local内存。在把变量从主内存读到自己的工作内存，修改之后，不一定会立即写入主存，因此另一个线程不可见。
要保证上述案例可以完全正确执行，需要在变量前加volatile。
volatile变量可以保证：每次对该变量的写，必定刷回到主存；每次对该变量的读，必定从主存读取。从而可以保证，一个线程对共享变量的写，对其他线程可见。
-volatile应用2 – 原子性
由于JMM并不要求对一个64位的long/double型的变量写入具有原子性，在32位的机器上，对一个long型变量的写入，可能会分成高32位，低32位2次写入。此时，另一个线程去读取时，可能读到“写了一半”的无效值！
要解决上述问题，可以加锁，也可以加volatile关键字。
可见，在对单个变量的读写中，volatile变量起到了锁同样的作用。
也正因为如此，在AtomicInteger/AtomicLong中，其get()/set()函数，都未加锁，却是线程安全的！！
-volatile应用3 – 构造函数逸出/DCL问题(Double Checking Locking)
线程安全的单例模式中，有一种经典写法，即DCL(Doule Checking Locking)，如下所示：
public class Sington
{
private static Sington instance;
public static Sington getInstance()
{
if(instance == null) //DCL
{
synchronized(Sington.class)
{
if(instance == null)
instance = new Instance(); //有问题的代码！！！
}
}
return instance;
}上述的new Instance()，底层可以分为3个操作: 分配内存，在内存上初始化成员变量，把instance指向内存。
这3个操作，可能重排序，即先把instance指向内存，再初始化成员变量。
此时，另外一个线程就会拿到一个未完全初始化的对象。这时直接访问里面的成员变量，就可能出错。而这就是典型的“构造函数溢出”问题。
要解决此问题，只要在instance前加volatile就可以了！
当然，还有另外1种经典的线程安全的单例模式 – 基于类加载器的方案
public class Instance
{
private static class InstanceHolder
{
public static Instance instance = new Instance();
}
public static Instance getInstance()
{
return InstanceHolder.instance;
}
}
-final应用1 – 避免构造函数重排序
答案是：a, b 未必一定等于1，2。因为这里的i, j都是非volatile变量，线程A的重排序，可能使得i, j的赋值，在构造函数之后执行！！也就是说，线程B拿到obj的时候，obj的i, j变量可能赋值还未完成！
解决办法是：给i, j 加上final，final的语义： 保证final变量的初始化，一定在构造函数返回之前完成！
-final应用2 – CopyOnWrite
在上1篇 NumberRange例子中，我们看到lower, power都是final类型，这也确保了lower, power只可能被赋值1次。后续要想再改变值，只能拷贝一份出来改！
所以，通常应用CopyOnWrite的地方，也会相应的使用final!
-atomic数组/volatile数组/final数组/ 
-指令重排序，happen before语义
从上述各种案例可以看出，问题主要出在“指令重排序”上。
为什么要指令重排序呢？
从程序员角度来讲，最好是不要有任何的指令重排，这样程序最容易理解；但从CPU和编译器角度，希望在不改变单线程程序语义的情况下，尽可能的重排序，最大程度的提高执行效率。
而对于多线程程序，因为重排序导致的线程之间的不同步，则由程序员自己处理！
volatile和final的底层原理，就是一定程度上禁止重排序，从而实现多线程程序的同步。
四、Java多线程 -- JUC包源码分析4 -- 各种锁与无锁
未看懂。。。。。。。。
五、Java多线程 -- JUC包源码分析5 -- Condition/ArrayBlockingQueue/LinkedBlockingQueue/Deque/PriorityBl
参考：http://blog.csdn.net/chunlongyu/article/category/6399716