乐观锁的缺点

ABA 问题

如果变量 V ，初次读取时是 A 值，并且在准备赋值的时候，检查到它仍然是 A 值，这样能否说明它的值，没有被其他线程修改过？答案是否定的，因为在这段时间内，它的值可能被更改为其他的值，然后又改回成了 A 值，那 CAS 操作就会误认为它从来没有被修改过。这个问题，被称为 CAS 操作的 ABA 问题。

JDK1.5 以后的 AtomicStampedReference 类提供了这样的功能，其中的 compareAndSet() 方法，就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，才会以原子的方式，将该引用和该标志的值，设置为给定的更新值。

循环时间长，开销大

自旋 CAS（也就是不成功就一直循环执行直到成功），如果长时间不成功，会给 CPU 带来非常大的执行开销。 如果 JVM 能支持处理器提供的 pause 指令，那么效率会有一定的提升，pause 指令有两个作用，第一，它可以延迟流水线执行指令（de-pipeline）,使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零；第二，它可以避免在退出循环的时候，因内存顺序冲突（memory order violation），而引起 CPU 流水线被清空（CPU pipeline flush），从而提高 CPU 的执行效率。

只保证单个共享变量的原子操作

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时，CAS 操作无效。但是从 JDK1.5 开始，提供了 AtomicReference 类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里，来进行 CAS 操作。所以可以使用锁，或者利用 AtomicReference 类，把多个共享变量合并成一个共享变量来操作。