乐观锁：高效并发无锁方案

于 2025-05-31 16:56:56 发布
阅读量798 收藏 17
点赞数 20
CC 4.0 BY-SA版权
分类专栏： JUC 文章标签： oracle 数据库 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/FQY__/article/details/148353412

4.乐观锁

这一章主要介绍乐观锁。前面的管程部分讲了悲观锁，现在做一些总结：

  1. 悲观锁（Pessimistic Lock）：悲观锁认为数据在多线程或多进程环境下总是容易发生冲突/冲突的概率高，所以在数据操作前，直接加锁（独占），别的线程/进程不能再访问或只能阻塞等待。因此悲观锁实用与写操作多、共享资源竞争激烈以及一致性要求高的场景。但是如果面对读操作多的情况，使用悲观锁会导致线程切换进而导致额外开销，就不如乐观锁。
  • 数据库层 ：SELECT ... FOR UPDATE，行锁、表锁
  • Java并发 ：synchronized，ReentrantLock，AQS独占锁等
  • 其他 ：文件锁、操作系统互斥锁
  1. 乐观锁（Optimistic Lock）：乐观锁假定冲突发生的概率低，不加锁，先操作，最后再校验 （即使有冲突，再补救）。因此乐观锁的过程是不涉及真实的锁，而是使用有冲突再补救的思想进行判断，因此不会涉及阻塞和互斥，性能较好，适用于读多写少的场景。但问题是如果在写多的场景下，会经常出现重试，也就会导致效率降低。且如果对于乐观锁的粒度要求高，会出现ABA问题。
  • CAS（Compare and Swap）机制 —— Java原子类AtomicInteger、AtomicReference等
  • 版本号机制 — 每条数据/对象带版本号，更新时校对版本号
  • 数据库乐观锁 ：如在UPDATE/DELETE时加条件“WHERE version = ?”，更新不成代表有别的事务改过了，重试

4.1 CAS

如果不加synchronized则会出现线程安全的问题，即cost不会为0。加synchronized则会解决线程安全的问题。即会因为多个线程操作amount可能会出现并发的问题。例如减余额的操作分为读取值、减余额，写回，这样两个线程都执行前两步，结果只扣了一次。

import java.util.ArrayList;
import java.util.List;
public class Main {
    public static void main(String[] args) {
        Account account = new AccountUnsafe(10000);
        Account.demo(account);
    }
}


class AccountUnsafe implements Account {
    private Integer balance;

    public AccountUnsafe(Integer balance) {
        this.balance = balance;
    }

    @Override
    public Integer getBalance() {
        synchronized (this) {
            return this.balance;
        }
    }

    @Override
    public void withdraw(Integer amount) {
        
            this.balance -= amount;
       
    }
}

interface Account{
    // 获取余额
    Integer getBalance();

    // 取款
    void withdraw(Integer amount);

    /**
     * 方法内会启动1000个线程，每个线程做-10元的操作
     * 如果初始余额为10000那么正确的结果应当是0
     */
    static void demo(Account account) {
        List<Thread> ts = new ArrayList<>();
        for (int i = 0; i < 1000; i++) {
            ts.add(new Thread(() -> {
                account.withdraw(10);
            }));
        }
        long start = System.nanoTime();
        ts.forEach(Thread::start);
        ts.forEach(t -> {
            try {
                t.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
        long end = System.nanoTime();
        System.out.println(account.getBalance()
                + " cost: " + (end - start) / 1000_000 + " ms");
    }
}
// 无锁实现 也可以做到全售卖出 整个过程不涉及sync
class AccountCas implements Account {
    private AtomicInteger balance;

    public AccountCas(int balance) {
        this.balance = new AtomicInteger(balance);
    }

    @Override
    public Integer getBalance() {
        return balance.get();
    }

    @Override
    public void withdraw(Integer amount) {
        while(true) {
            // 获取余额的最新值
            int prev = balance.get();
            // 要修改的余额
            int next = prev - amount;
            // 真正修改
            if(balance.compareAndSet(prev, next)) {
                break;
            }
        }
    }

}

无锁原理：

重点在于compareAndSet,即CAS。比较的双方如下：

  • prev：调用balance.get()时读取的余额值（旧值）。
  • balance的当前实际值：执行CAS时内存中的最新值。

也就是，检查balance的当前值是否等于prev（即判断是否有其他线程在此期间修改了余额）。如果是等于，则说明并未被修改，因此将next赋值给balance，并且立即写入主内存。反之则继续循环。

而怎么保证cas操作是原子的？现代处理器提供了专门的原子指令来实现CAS操作，即只有一条指令来进行CAS。

线程1Account对象线程2获取余额(100)计算新值(100-10=90)CAS(100→90) 成功余额=90获取余额(90)计算新值(90-10=80)CAS(90→80) 成功余额=80获取余额(80)计算新值(80-10=70)CAS(80→70) 成功余额=70线程1Account对象线程2

CAS和volatile：

我们使用的AtomicInteger，具体值是使用volatile进行修饰，因此会插入内存屏障保证其可见性。如果不加入volatile，则可能一直看不到最新值，导致一直死循环，因此CAS必须配合volatile才可以使用。

无锁效率：

无锁的效率更高，因为cas的自选操作不需要切换上下文，而sync需要切换上下文，多出开销。但是CAS需要额外的cpu的支持，不然就没有实际意义。也因此最好线程数不要超过cpu数，超过了再自旋也没有意义。

总结：

  1. cas是乐观锁的思想，即认为发生冲突的情况很少，遇到冲突则会重试。而sync是悲观锁，假设冲突经常发生。
  2. cas是无锁且无阻塞的并发。即真的不加锁，且状态不改变不是阻塞态。如果竞争如果十分激烈，重试经常发生则会效率降低。

4.2 无锁线程安全工具，原子类

原子类的全部方法都保证了原子性，其原子性的原因仍为cas+volatile。例如AtomicInteger的源码有一个int value代表值，这个变量就是使用volatile修饰，每次读取一定读取到最新值，不会脏读。CAS则是指令保证的。

这里说一下，Integer、String等类都是线程安全的，也就是不可变类，即一旦创建状态就不可以修改。也因此多线程的读写不会影响对象本身。但下面的操作就发生了读-写-改的操作，多线程下这样的操作就不是原子的，因此原子类就是解决类似读-写-改这样的多次操作，从而保证多线程下的原子性。

Integer a = 1;
// Thread A
a = a + 1;        // 等价于 int tmp = a.intValue(); tmp++; a = new Integer(tmp); 
// Thread B
a = a + 1;
4.2.1 原子整数

有如下方法，方法都保证原子性：

AtomicInteger i = new AtomicInteger(0);

// 获取并自增（i = 0, 结果 i = 1, 返回 0），类似于 i++
System.out.println(i.getAndIncrement());

// 自增并获取（i = 1, 结果 i = 2, 返回 2），类似于 ++i
System.out.println(i.incrementAndGet());

// 自减并获取（i = 2, 结果 i = 1, 返回 1），类似于 --i
System.out.println(i.decrementAndGet());

// 获取并自减（i = 1, 结果 i = 0, 返回 1），类似于 i--
System.out.println(i.getAndDecrement());

// 获取并加值（i = 0, 结果 i = 5, 返回 0）
System.out.println(i.getAndAdd(5));

// 加值并获取（i = 5, 结果 i = 10, 返回 10）
System.out.println(i.addAndGet(5));

// 更新并获取，适合复杂操作。即将得到的value值*10再获取，输出为100.
System.out.println(i.updateAndGet(value -> value*10));

因此有了上面的原子的方法，我们之前的代码就可以做如下修改。更改后的代码不需要在手动写CAS进行循环判断，而是交给getAndAdd方法，其内部也是CAS的操作。

@Override
public void withdraw(Integer amount) {
    /*while(true) {
        // 获取余额的最新值
        int prev = balance.get();
        // 要修改的余额
        int next = prev - amount;
        // 真正修改
        if(balance.compareAndSet(prev, next)) {
            break;
        }
    }*/
    balance.getAndAdd(delta: -1*amount);
}

updateAndGet原理：

思想还是使用compareAndSet进行判断。不过需要传入一个一元的操作符来代表操作。

public final int updateAndGet(IntUnaryOperator updateFunction) {
    int prev, next;
    do {
        prev = get();
        next = updateFunction.applyAsInt(prev);
    } while (!compareAndSet(prev, next));
    return next;
}
4.2.2 原子引用

想保护的不一定都是基本数据类型，因此使用原子引用类型。比如我们把上面的例子的Integer类型替换为BigDecimal类型，那就不能使用AtomicInteger类型，可以使用原子引用类型。

class DecimalAccountCas implements DecimalAccount {
    private AtomicReference<BigDecimal> balance; // 在泛型的部分加入需要替换的类型

    public DecimalAccountCas(BigDecimal balance) { // 构造函数，传入balance
        this.balance = new AtomicReference<>(balance);
    }

    @Override
    public BigDecimal getBalance() {
        return balance.get();
    }

    @Override
    public void withdraw(BigDecimal amount) {
        while(true) {
            BigDecimal prev = balance.get();
            BigDecimal next = prev.subtract(amount);
            if (balance.compareAndSet(prev, next)) {
                break;
            }
        }
    }
}

原子引用的ABA问题：

例如有如下一段代码：

public class Test {
    static AtomicReference<String> ref = new AtomicReference<>("A");

    public static void main(String[] args) throws InterruptedException {
        Log.debug("main start...");
        // 获取值 A
        String prev = ref.get();
        other();
        sleep(1);
        // 尝试改为 C
        Log.debug("change A->C {}", ref.compareAndSet(prev, update: "C"));
    }

    private static void other() {
        new Thread(() -> {
            Log.debug("change A->B {}", ref.compareAndSet(ref.get(), update: "B"));
        }, name: "t1").start();
        sleep(0.5);
        new Thread(() -> {
            Log.debug("change B->A {}", ref.compareAndSet(ref.get(), update: "A"));
        }, name: "t2").start();
    }
}

这一段代码的main线程会sleep 1s，期间other会主动改动ref的值为B再改为A，但是main线程无法判断是否有其他线程更改过。因此，CAS无法判断是否有其他线程进行修改。虽然大部分情况这种问题不会导致真正的问题，因为最后main判断的数据仍然为A，但是如果希望只要发生修改就返回false，则仅仅比较值是不够的，还需要增加一个版本号。每次修改都会更改版本号。需要替换原子引用，使用AtomicStampedReference，即原子版本号引用。

如下代码，other中的两个线程都可以修改，并且会递增版本号，但是main线程则会由于版本号对不上CAS失败。

public class AtomicStampedReferenceExample {
    static AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 0);

    public static void main(String[] args) throws InterruptedException {
        Log.debug("main start...");
        // 获取值 A
        String prev = ref.getReference();
        int stamp = ref.getStamp();
        other();
        // 尝试改为 C
        Log.debug("change A->C {}", ref.compareAndSet(prev, "C", stamp, stamp + 1));
    }

    private static void other() {
        new Thread(() -> {
            int stamp = ref.getStamp();
            Log.debug("change A->B {}", ref.compareAndSet(ref.getReference(), "B", stamp, stamp + 1));
        }, "t1").start();
      sleep(0.5);
        new Thread(() -> {
            int stamp = ref.getStamp();
            Log.debug("change B->A {}", ref.compareAndSet(ref.getReference(), "A", stamp, stamp + 1));
        }, "t2").start();
    }
}

有时候，不关心更改多少次而是是否做过更改，因此就可以使用AtomicMarkableReference。

ABA问题主要是在乐观锁/CAS并发更新时，内存（或数据/引用）先变成A→B，然后又变回A，因此会误以为没有被修改，实则被修改了。主要出现在原子引用/CAS操作时出现。

4.2.3 原子数组

是一种原子的，可以在多线程下使用的数组。其实就是可以替换数组，也就是int[]

private static <T> void demo(
    Supplier<T[]> arraySupplier,
    Function<T[], Integer> lengthFun,
    BiConsumer<T[], Integer> putConsumer,
    Consumer<T[]> printConsumer) {
    
    List<Thread> ts = new ArrayList<>();
    T[] array = arraySupplier.get();
    int length = lengthFun.apply(array);
    
    for (int i = 0; i < length; i++) {
        // 每个线程对数组作10000次操作
        ts.add(new Thread(() -> {
            for (int j = 0; j < 10000; j++) {
                putConsumer.accept(array, j % length);
            }
        }));
    }
}
// 测试函数
demo(
    // 换成Atomic就不会出错
    // 如果是() -> new int[10] 就会因为线程不安全导致出错。
    () -> new AtomicIntegerArray(length: 10),
    (array) -> array.length(),
    (array, index) -> array.getAndIncrement(index),
    array -> System.out.println(array)
);
4.2.4字段更新器：

字段更新器，是更新一个类的某个字段的方式，这个字段必须要被volatile进行修饰。例如一个class里有一个叫account的属性，那么可以通过字段更新器进行原子更改（使用原子方法，例如cas，getAndAnd）。相比于直接使用原子整数或者原子引用，字段更新器不会额外创建原子对象，因此开销更小。但是属性一定要被volatile修饰，且不能为static。

import java.util.concurrent.atomic.AtomicIntegerFieldUpdater;

public class FieldUpdaterExample {
    static class BankAccount {
        private volatile int balance; // 必须是 volatile
        private static final AtomicIntegerFieldUpdater<BankAccount> updater =
            AtomicIntegerFieldUpdater.newUpdater(BankAccount.class, "balance"); // 对BankAccount的balance字段进行更改。

        public void withdraw(int amount) {
            updater.addAndGet(this, -amount); // 原子扣减
        }

        public int getBalance() {
            return balance;
        }
    }

    public static void main(String[] args) {
        BankAccount account = new BankAccount();
        account.withdraw(100); // 原子操作
        System.out.println("Balance: " + account.getBalance());
    }
}

对于除了Integer的对象，也有对应类型的字段更新器：

AtomicIntegerFieldUpdater //用于 int 类型字段。
AtomicLongFieldUpdater //用于 long 类型字段。
AtomicReferenceFieldUpdater //用于引用类型字段（如 String、自定义对象）。
4.2.5 原子累加器

顾名思义，就是做累加操作的。

4.3 LongAdder

用于在高并发的场景下替代AtomicLong，因为AtomicLong是基于CAS的，如果在高并发下多线程进行竞争可能会导致性能瓶颈。而LongAdder将计数分散到多个变量（多个cell），不同的线程竞争不同的cell，进而减少竞争。

有如下关键字段：

transient volatile Cell[] cells;

transient volatile long base;

transient volatile int cellsBusy; // 表示cells初始化/扩容等是否在进行中
  • base：计数基础值。并发不高时，线程直接尝试 CAS 操作它。
  • cells：Cell 数组，高并发时，线程 hash 到不同 Cell 进行累加。
  • cellsBusy：自旋锁，保证 cells 操作线程安全。

而这里的cell本质是一个包含 volatile long 的对象，并能支持自身的 CAS 操作。

// 防止缓存行的伪共享
@sun.misc.Contended
static final class Cell {
    volatile long value;
    Cell(long x) { value = x; }
    final boolean cas(long cmp, long val) {
        return UNSAFE.compareAndSwapLong(this, valueOffset, cmp, val);
    }
}

这里的注解是防止伪共享。什么是伪共享呢？伪共享 是多线程并发编程中的一种性能隐患。当多个线程操作不同变量 ，但这些变量共享同一个CPU缓存行时，如果线程频繁写操作这些变量，会导致缓存行反复失效（cache line flush），极大降低并发性能。这种情况下虽然线程没有真正访问同一份数据，但会“间接竞争”同一缓存行。

cpu是分级缓存的，我们这里只假设有一个cache，对于多核cpu来说，每个cpu则会配置一个cache。但是内存只有一份。一个cache行和内存行的大小是相同的，都是64字节，而存储的cell则是24字节（对象头16+一个long变量8），**也就是说一个内存行可以存储两个cell。**如果一个cpu1将cell0的值+1，而另一个cpu2只是将cell1+1，那么对应到内存中会触发同一cache line的竞争和cache一致性协议（如MESI）下的共享失效（false sharing），因此会导致一致性问题。

解决方法也就是加入注解：Cell 填充(padding)——@sun.misc.Contended

@sun.misc.Contended
static final class Cell {
   volatile long value;
   // ...
}

JVM看到 @Contended，会自动帮Cell对象在value前后填充一些“无用字节”（padding），防止同一个Cell数组里的Cell落在同一缓存行，提高并发写性能。简单来说，也就是每个cell独占一个cache行，不会出现多个cell挤在一个cache行的情况。

常用方法：
  1. add(long x)：
    增加指定的值（x可以是正数或负数，即加也可以减）。
  2. increment()：
    自增1，等价于add(1)。
  3. decrement()：
    自减1，等价于add(-1)。
  4. sum()：
    获取当前所有Cell+base的累计和（近似实时值，不是强一致性）。这里是即使快照，可能在取得sum的时候有其他线程进行修改，但只是获取的值可能是上一个版本的值，但是能保证值是正确的。
  5. sumThenReset()：
    获取累计和，并顺带清空为0（适合做周期性采集和清空，比如监控流量时段统计）。
  6. reset()：
    直接重置所有统计为0，但不返回和。

源码如下： 这里的cells就是Longadder的cells数组，而cells是懒创建的，没有竞争时就不创建cells。base也是Longadder的base字段，如果base的CAS失败，则说明出现竞争。这两点都说明竞争出现了，进入if分支。如果没有发生竞争，则在casBase的地方就直接进行了累加。

第二个if分支则是查看是否要进入复杂分支，即简单路径是否失败。

public void add(long x) {
    Cell[] as; 
    long b, v;
    int m;
    Cell a;
    // 1. 如果cells数组已初始化 或 base的CAS失败 
    if ((as = cells) != null || !casBase(b = base, b + x)) {
        boolean uncontended = true;
        // 2. 尝试定位到cell 
        
        if (as == null || (m = as.length - 1) < 0 ||
            (a = as[getProbe() & m]) == null ||
            !(uncontended = a.cas(v = a.value, v + x)))
            // 3. 碰撞等特殊情况，进入更复杂的处理
            longAccumulate(x, null, uncontended);
    }
}

4.4 Unsafe

Unsafe 是 sun.misc.Unsafe 类的简称，是JVM提供的一个底层操作工具类。它允许你直接操纵内存、对象、线程、CAS原语等，抛开了 Java 普通语法和安全机制。因此这里的unsafe是指编程人员直接操作很不安全，而不是这个类不安全。

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值