1. 悲观锁

互斥同步最主要的问题就是线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步。
互斥同步属于一种悲观的并发策略：总是认为只要不去做正确的同步措施，那就肯定会出现问题。无论共享数据是否真的会出现竞争，它都要进行加锁。

Java 中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。

2. 乐观锁

乐观锁基于冲突检测的乐观并发策略：先进行操作，如果没有其他线程争用共享数据，操作成功；如果数据存在竞争，就采用补偿措施（常见的有不断重试，直到成功）。这种乐观的并发策略的许多实现是不需要将线程挂起的，因此这种同步操作称为非阻塞同步。

3. CAS

乐观锁需要操作和冲突检测这两个步骤具备原子性，这里就不能再使用互斥同步来保证了，只能靠硬件来完成。

硬件支持的原子性操作最典型的是：CAS（Compare-and-Swap）。

当多个线程尝试使用 CAS 同时更新一个共享变量时，只有其中一个线程能够更新共享变量中的值，其他线程都失败，失败的线程不会被挂起，而是被告知在这次竞争中失败，并且可以再次尝试。

CAS 指令需要有 3 个操作数，分别是内存地址 V、旧的预期值 A 和新值 B。当执行操作时，只有当 V 的值等于 A，才将 V 的值更新为 B。

使用 CAS 带来的问题：

  • ABA 问题
    如果一个变量初次读取的时候是 A 值，它的值被改成了 B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。
    J.U.C 包提供了一个带有标记的原子引用类 AtomicStampedReference 来解决这个问题，它可以通过控制变量值的版本来保证 CAS 的正确性。大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。
  • 只能保证一个共享变量的原子操作
    JDK 1.5 以后，使用 AtomicReference 将多个共享变量封装为一个共享变量进行操作。
  • 自旋时间长开销大
    自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给 CPU 带来非常大的执行开销。