一篇轻松的couchbase上的译文：

http://www.csdn.net/article/2012-12-12/2812708-leguansuo-beiguansuo-couchbase

其中有一句很启发我：如果一个线程已经获得了一个锁，而OS又没有对这个锁的安排；那么其他想争用这个锁的线程将会被阻塞。当然其中的一个选择就是避免完全加锁

 

http://blog.csdn.net/pi9nc/article/details/3917734

这篇文章，和我的研究思想是一样，我很高兴，有和我思路一样的人（已加好友），而且还能总结的这么好。最后他提出的问题也是非常的好：

①  乐观锁只能保证一个共享变量的原子操作。如上例子，自旋过程中只能保证value变量的原子性，这时如果多一个或几个变量，乐观锁将变得力不从心，但互斥锁能轻易解决，不管对象数量多少及对象颗粒度大小。（涉及到AtomicLong，Atomicreference的同步和现今的解决方案，后期会添加上）

②  长时间自旋可能导致开销大。假如CAS长时间不成功而一直自旋，会给CPU带来很大的开销。

③  ABA问题。CAS的核心思想是通过比对内存值与预期值是否一样而判断内存值是否被改过，但这个判断逻辑不严谨，假如内存值原来是A，后来被一条线程改为B，最后又被改成了A，则CAS认为此内存值并没有发生改变，但实际上是有被其他线程改过的，这种情况对依赖过程值的情景的运算结果影响很大。解决的思路是引入版本号，每次变量更新都把版本号加一。（ABA问题还在研究中）