一文带你了解乐观锁和悲观锁的本质区别！

悲观锁是什么？

悲观锁它总是假设最坏的情况，它会认为共享资源在每次被访问的时候就会出现线程安全问题，所以每次在获取资源的时候都会上锁，以避免线程安全问题发生。

也就是说，共享资源每次只给一个线程使用，而其他的线程则会阻塞住，当占据锁的线程用完后才会把共享资源释放掉，让给其它线程来进行竞争。

这样就会导致在高并发的场景下容易造成死锁、以及线程阻塞等，增加系统的开销。

乐观锁是什么？

乐观锁总是假设最好的情况，它认为共享资源每次被访问的时不会出现线程问题，所以也就不用加锁去保证线程安全，因此线程可以不停地执行，只有当提交修改的时候去验证对应的共享资源是否被其它线程修改。

高并发的场景下，乐观锁不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。
但是，如果写操作的冲突频繁发生，会频繁失败和重试，这样同样会非常影响性能。

如何实现乐观锁？

什么是CAS

CAS是Compare-And-Swap（比较并交换）的缩写，是一种轻量级的同步机制，主要用于实现多线程环境下的无锁算法和数据结构，保证了并发安全性。它可以在不使用锁的情况下，对共享数据进行线程安全的操作。

它就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。CAS 操作是一个原子操作，它在执行期间不会被其他线程中断。因此，它能够提供一种乐观并发控制机制，避免了传统锁机制的开销和可能的线程阻塞。

它的其实主要就是两个步骤：冲突检测以及数据更新。

通常包含三个参数：内存位置（或称为变量）、期望值和新值。它的执行步骤如下：
  1. 读取内存位置的当前值。
  2. 检查当前值是否与期望值相等。如果相等，则进行步骤4；如果不相等，则说明其他线程已经修改了该值，操作失败。
  3. 如果当前值与期望值相等，则将新值写入内存位置。
  4. 返回操作是否成功的标志。

class AccountSafe implements Account {private AtomicInteger balance; // 原子整数类型 public AccountSafe(Integer balance) {this.balance = new AtomicInteger(balance);}@Overridepublic Integer getBalance() {return balance.get();}@Overridepublic void withdraw(Integer amount) {while (true) {// 没同步到主存 因为是局部变量，只在线程的工作内存之中int prev = balance.get(); // 获取余额最新值int next = prev - amount; // 修改后的余额// 真正修改if (balance.compareAndSet(prev, next)) { // 成功为true；失败false,继续循环 break;}}}
}

我们再来仔细看一下withdraw方法

public void withdraw(Integer amount) {// 需要不断尝试，直到成功为止while (true) {// 比如拿到了旧值 1000int prev = balance.get();// 在这个基础上 1000-10 = 990int next = prev - amount;/*compareAndSet 正是做这个检查，在 set 前，先比较 prev 与 当前值！！！当不一致时，next 作废，返回 false 表示失败比如，别的线程已经做了减法，当前值已经被减成了990那么本线程的这次 990 就作废了，进入 while 下次循环重试直到一致，以 next 设置为新值，返回 true 表示成功*/if (balance.compareAndSet(prev, next)) {break;}}
}

在并发环境中，多个线程可以同时执行CAS操作来更新同一个内存位置的值。如果多个线程同时执行CAS操作，只有一个线程的CAS操作会成功，其他线程的操作将失败。在失败的情况下，可以选择重试CAS操作。

应用

1. JVM创建对象的过程中分配内存【堆中 因为这个是共享 所以要保证安全】
2. syn轻量级锁的时候，JVM尝试使用CAS操作，将对象头的Mark Word更新为指向锁记录的指针。
3. ReentrantLock中的非公平锁，也使用CAS来管理锁的状态。比如，尝试获取锁时会使用CAS来检查并更新锁的状态。
4. 并发集合：如ConcurrentHashMap等，并发集合的实现中也大量使用了CAS操作，以实现高效的线程安全访问。
5. 原子类：如AtomicInteger、AtomicLong、AtomicReference等，这些类提供了一组原子操作，允许你在单个操作中安全地读取、写入和更新变量。这些操作背后就是通过CAS来实现的。

局限性

1. 只能保证对单个共享变量的操作是原子性的，无法保证对多行代码实现原子性
2. 高并发场景下，竞争激烈，CAS 失败重试会频繁发生，自旋时间过长，而线程又不阻塞，抢占 CPU 资源，导致 CPU 使用率飙升，反而影响了性能
   a. 指定 CAS 一共循环多少次，如果超过这个次数，直接失败或将线程挂起(参考 synchronized 中的自旋锁) .
   b. 可以通过分段的思想减少竞争，使用原子累加器 LongAdder，当有竞争时设置多个累加单元，最后将结果汇总
3. ABA问题

ABA问题是什么？

先看例子：

假设你在银行的查看账户余额。第一次查看时，余额显示为100元（状态A）。然后打算取出50元，但在操作之前，出于确认目的，再次检查余额，发现还是100元，似乎没有变化（仍然是状态A）。

但实际情况可能是，在两次查看之间，有人往你的账户存入了50元（状态变为B：150元），然后又立即取出了50元（状态再次回到A：100元）。尽管最终余额回到了初始查看的数值，但实际上账户经历了存取的变化（A->B->A）。

在并发编程的上下文中，这就是“ABA问题”。当你CAS操作来确保数据一致性时，如果仅比较前后值是否相同（都是A），就可能会忽略掉中间发生的改变（B状态），误以为数据从未被改动过，从而可能导致逻辑错误或数据不一致性！

如何解决？

解决ABA问题的一种常见方法是引入版本号或者时间戳，每次修改变量时不仅更新其值，还增加版本号或时间戳。这样，即便值回到了最初的状态，通过检查版本号或时间戳的不同，也可以察觉到变量曾经被修改过。

AtomicStampedReference(维护版本号)
AtomicStampedReference通过捆绑一个引用及其关联的stamp（印记，可以视为版本号或时间戳）来工作，以此增强传统的比较并交换（CAS）操作。

它允许线程在执行 CAS 操作时，不仅检查引用是否发生了变化，还要检查时间戳是否发生了变化。这样，即使一个变量的值被修改后又改回原值，由于时间戳的存在，线程仍然可以检测到这中间的变化。

public class AtomicStampedReferenceDemo {private static final Logger log = LoggerFactory.getLogger(AtomicStampedReferenceDemo.class);static AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 0);public static void main(String[] args) throws InterruptedException {log.debug("main start...");// 获取值 AString prev = ref.getReference();// 获取版本号int stamp = ref.getStamp();log.debug("版本 {}", stamp);// 如果中间有其它线程干扰，发生了 ABA 现象other();TimeUnit.MILLISECONDS.sleep(1); // 使用TimeUnit使代码更具可读性// 尝试改为 Clog.debug("change A->C {}", ref.compareAndSet(prev, "C", stamp, stamp + 1));}private static void other() {new Thread(() -> { // 更新如果成功，版本号加1log.debug("change A->B {}", ref.compareAndSet(ref.getReference(), "B",ref.getStamp(), ref.getStamp() + 1));log.debug("更新版本为 {}", ref.getStamp());}, "t1").start();TimeUnit.MILLISECONDS.sleep(500); // 确保t1先启动new Thread(() -> {log.debug("change B->A {}", ref.compareAndSet(ref.getReference(), "A",ref.getStamp(), ref.getStamp() + 1));log.debug("更新版本为 {}", ref.getStamp());}, "t2").start();}private static void sleep(long millis) {try {Thread.sleep(millis);} catch (InterruptedException e) {Thread.currentThread().interrupt();throw new RuntimeException(e);}}
}

AtomicMarkableReference(仅维护是否修改过)
与AtomicStampedReference不同，它通过一个布尔标记（mark），来简单指示引用的对象是否曾被修改过。
这个类在执行CAS时，不仅关注引用本身的比较，还会检查这个伴随的标记状态。即，哪怕对象的值在一段时间内经历了A->B->A，由于标记的存在，线程也能够感知到该对象曾经发生过变化。

// GarbageBag类定义
class GarbageBag {private String desc;public GarbageBag(String desc) {this.desc = desc;}public void setDesc(String desc) {this.desc = desc;}@Overridepublic String toString() {return "GarbageBag{" +"desc='" + desc + '\'' +'}';}
}public class TestABAAtomicMarkableReference {private static final Logger log = LoggerFactory.getLogger(TestABAAtomicMarkableReference.class);public static void main(String[] args) throws InterruptedException {GarbageBag bag = new GarbageBag("装满了垃圾");// 参数2 mark 可以看作一个标记，表示垃圾袋是否已满AtomicMarkableReference<GarbageBag> ref = new AtomicMarkableReference<>(bag, true);log.debug("主线程 start...");GarbageBag prev = ref.getReference();log.debug(prev.toString());new Thread(() -> {log.debug("打扫卫生的线程 start...");bag.setDesc("空垃圾袋"); // 假设这里清理了垃圾袋// 尝试将标记从true改为false，表示垃圾袋已清空while (!ref.compareAndSet(bag, bag, true, false)) {}log.debug(bag.toString());}).start();TimeUnit.SECONDS.sleep(1); // 等待打扫卫生的线程执行log.debug("主线程想换一只新垃圾袋？");boolean success = ref.compareAndSet(prev, new GarbageBag("空垃圾袋"), true, false);log.debug("换了么？" + success);log.debug(ref.getReference().toString());}
}

其他文章

从底层源码剖析AQS的来龙去脉！（通俗易懂）