Java Unsafe CAS与可见性

看JUC源码突然发现没用volatile关键字修饰这些变量，哼哼，有点意思。

想了想，CAS用的指令是lock cmpxchg，那么关键点就在这个lock指令。

试问，如果CAS连可见性都保存不了，CAS那还敢谈什么正确性呢？
如果在比较并交换时，比较的是CPU缓存中的变量值，那肯定是不行的。于是在cmpxchg前加了lock指令，强制将CPU缓存中变动过的（例如被MESI判断为失效）变量刷回主存，于是Unsafe类的CAS操作可以保证正确。
因此，CAS的指令实现lock总是与cmpxchg一起出现，以保证可见性，lock cmpxchg便是Unsafe#CAS的实现。

回到正题，为什么没用volatile？
这个问题就很好回答了，先看图，ArrayBlockingQueue#put：

ArrayBlockingQueue的实现中，对queue的增删改查都是用ReentrantLock加了锁的。
在ReentrantLock的实现中，lock上锁过程中用到了unsafe.compareAndSwapInt(this, stateOffset, expect, update)——CAS，也就包含了lock指令，于是就将lock.lockInterruptibly()代码执行之前失效的变量刷回了主存，也就无需再用volatile修饰ArrayBlockingQueue中这些私有变量了。

综上，我们平时写代码：

int a;
write:
	ReentrantLock#lock();
	a = 10;
	ReentrantLock#unlock();
read1:
	println(a);
read2:
	ReentrantLock#lock();
	println(a);
	ReentrantLock#unlock();

这样锁住后读写，也就无需将a声明为volatile。