当前位置：首页 > news >正文

Java 多线程之 CAS（Compare and Set），实现无锁优化，自旋锁/乐观锁

news 2025/7/28 21:41:32

文章目录

- 一、概述
- 二、JDK 的 Unsafe 类
- 三、ABA 问题

一、概述

CAS（Compare and Swap）是一种并发编程中的原子操作（synchronized 也使用了 CAS），用于实现多线程环境下的同步和数据共享。CAS提供了一种高效的并发控制机制，可以避免传统锁机制的开销和问题。
CAS操作包括三个操作数：内存位置（通常是共享的变量）、旧的预期值和新的值。
- CAS操作会先比较内存位置上的值与旧的预期值是否相等，如果相等，则将新的值写入该内存位置；如果不相等，则说明其他线程已经修改了该内存位置的值，CAS操作失败，不会进行写入操作。
CAS的优势和应用场景如下：
1. 非阻塞：CAS是一种非阻塞的原子操作，不会引起线程的阻塞和切换，提高了并发性能。
2. 原子性：CAS操作是原子的，要么成功执行写入操作，要么失败不写入，不存在中间状态。
3. 无锁：CAS不需要使用传统锁机制（如互斥锁）来保护共享资源，避免了锁带来的线程阻塞和上下文切换开销。
4. 并发控制：CAS可以用于并发控制，例如实现线程安全的计数器、自旋锁、无锁队列等数据结构。
5. 无死锁：由于CAS不使用锁，因此不存在死锁的问题。
尽管CAS具有上述优势，但也存在一些限制和注意事项：
1. ABA问题：CAS只能检测到预期值是否相等，无法感知到变量值的修改过程中是否发生了其他的并发修改，可能会引发ABA问题。
2. 自旋次数：在CAS操作失败时，为了尝试成功，可能会进行自旋操作，如果自旋次数过多，会消耗过多的CPU资源。
3. 适用性：CAS适用于共享变量的简单操作，对于复杂的操作可能不适合使用CAS。
java.util.concurrent.atomic.Atomic* 开头的类都用 CAS 实现无锁优化。

二、JDK 的 Unsafe 类

Unsafe 提供了一系列低级的、直接操作内存和线程的方法，属于 Java 的核心库之一。由于 Unsafe 提供了直接操作内存和线程的能力，因此它具有很大的潜在危险性，一般建议开发者避免直接使用它，尽量使用更高级别的抽象和标准库提供的功能。
下面是 Unsafe 类的一些常见用途：
- CAS 操作：Unsafe 提供了一系列的 CAS（Compare and Swap）操作方法，用于实现原子性操作，如原子更新字段、原子更新数组等。
```
// unsafe 类使用 CAS 的方法的代码片段
public final class Unsafe {public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
}
```
- 直接内存操作：Unsafe 提供了分配和释放直接内存的方法，可以绕过 Java 堆内存的管理，直接操作底层的内存区域。有allocateMemory、freeMemory、putXX、pageSize类似于C语言中malloc，free等方法。
- 线程操作：Unsafe 提供了线程的挂起、恢复、创建和销毁等方法，可以直接操作线程。
- 数组操作：Unsafe 可以直接操作数组的内存，并提供了一些方法来获取数组元素的偏移地址、更新数组元素等。
- 内存屏障操作：Unsafe 提供了内存屏障（Memory Barrier）的操作方法，用于控制内存的可见性和指令重排序。
- 直接生类实例allocateInstance，直接操作类或实例变量objectFieldOffset、getInt、getObject，CAS相关操作weakCompareAndSetObject Int Long。

三、ABA 问题

ABA 问题对值类型没有问题，有问题的是对象类型。

ABA 问题描述
- ABA 问题是指在并发环境下，当一个变量的值从 A 变为 B，然后再变回 A，导致某些操作无法正确检测到中间的变化。
- ABA 问题的典型场景是使用 CAS（Compare and Swap）操作时发生。CAS 操作涉及比较当前内存位置的值与期望值，如果相等，则进行交换。然而，在一个线程执行 CAS 操作的过程中，其他线程可能修改了内存位置的值，然后又恢复为原始值，这样 CAS 操作将会成功，但实际上内存位置的值已经发生了变化。
下面一个简化的示例来说明 ABA 问题：
- 假设有两个线程 T1 和 T2，共享一个变量 value 的初始值为 A。执行过程如下：
  - （1）T1 读取 value 的当前值 A。
  - （2）在 T1 进行 CAS 操作之前，T2 修改 value 的值为 B。
  - （3）T2 又将 value 的值修改回 A。
  - （4）T1 执行 CAS 操作，发现 value 的当前值仍然是 A，CAS 操作成功。
- 在这个例子中，T1 使用 CAS 操作时，期望值是 A，实际上经历了从 A 到 B 再到 A 的变化。尽管 CAS 操作成功，但是它无法感知到中间的 B 的变化，从而可能导致意外的结果。
ABA 问题可能会对某些场景产生影响，例如使用 CAS 操作来实现并发数据结构，或者在实现一些复杂的算法时。为了解决 ABA 问题，需要额外的手段来检测变化，例如使用版本号、标记位或引入额外的同步机制。
在 Java 中，AtomicStampedReference 类是专门设计用于解决 ABA 问题的。它通过引入版本号来区分不同的状态，从而检测到变化。