Java 多线程之 CAS(Compare and Set),实现无锁优化,自旋锁/乐观锁

文章目录

    • 一、概述
    • 二、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 问题的。它通过引入版本号来区分不同的状态,从而检测到变化。

你可能感兴趣的:(#,Java,多线程,java,开发语言,多线程)