quarkus依赖注入之九：bean读写锁

V2AS问路

quarkus依赖注入之九：bean读写锁

阅读原文时间：2023年08月09日阅读：1

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码)：https://github.com/zq2599/blog_demos

本篇概览

本篇是《quarkus依赖注入》的第九篇，目标是在轻松的气氛中学习一个小技能：bean锁
quarkus的bean锁本身很简单：用两个注解修饰bean和方法即可，但涉及到多线程同步问题，欣宸愿意花更多篇幅与各位Java程序员一起畅谈多线程，聊个痛快，本篇由以下内容组成

关于多线程同步问题
代码复现多线程同步问题
quarkus的bean读写锁

关于读写锁

java的并发包中有读写锁ReadWriteLock：在多线程场景中，如果某个对象处于改变状态，可以用写锁加锁，这样所有做读操作对象的线程，在获取读锁时就会block住，直到写锁释放
为了演示bean锁的效果，咱们先来看一个经典的多线程同步问题，如下图，余额100，充值10块，扣费5块，正常情况下最终余额应该是105，但如果充值和扣费是在两个线程同时进行，而且各算各的，再分别用自己的计算结果去覆盖余额，最终会导致计算不准确

代码复现多线程同步问题

咱们用代码来复现上图中的问题，AccountBalanceService是个账号服务类，其成员变量accountBalance表示余额，另外有三个方法，功能分别是：

get：返回余额，相当于查询余额服务
deposit：充值，入参是充值金额，方法内将余额放入临时变量，然后等待100毫秒模拟耗时操作，再将临时变量与入参的和写入成员变量accountBalance
deduct：扣费，入参是扣费金额，方法内将余额放入临时变量，然后等待100毫秒模拟耗时操作，再将临时变量与入参的差写入成员变量accountBalance

AccountBalanceService.java源码如下，deposit和deduct这两个方法各算各的，丝毫没有考虑当时其他线程对accountBalance的影响

package com.bolingcavalry.service.impl;

import io.quarkus.logging.Log;
import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class AccountBalanceService {

// 账户余额，假设初始值为100
int accountBalance = 100;

/**
 * 查询余额
 * @return
 */
public int get() {
    // 模拟耗时的操作
    try {
        Thread.sleep(80);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return accountBalance;
}

/**
 * 模拟了一次充值操作，
 * 将账号余额读取到本地变量，
 * 经过一秒钟的计算后，将计算结果写入账号余额，
 * 这一秒内，如果账号余额发生了变化，就会被此方法的本地变量覆盖，
 * 因此，多线程的时候，如果其他线程修改了余额，那么这里就会覆盖掉，导致多线程同步问题，
 * AccountBalanceService类使用了Lock注解后，执行此方法时，其他线程执行AccountBalanceService的方法时就会block住，避免了多线程同步问题
 * @param value
 * @throws InterruptedException
 */
public void deposit(int value) {
    // 先将accountBalance的值存入tempValue变量
    int tempValue  = accountBalance;
    Log.infov("start deposit, balance [{0}], deposit value [{1}]", tempValue, value);// 模拟耗时的操作
try {
    Thread.sleep(100);
} catch (InterruptedException e) {
    e.printStackTrace();
}

tempValue += value;

// 用tempValue的值覆盖accountBalance，
// 这个tempValue的值是基于100毫秒前的accountBalance计算出来的，
// 如果这100毫秒期间其他线程修改了accountBalance，就会导致accountBalance不准确的问题
// 例如最初有100块，这里存了10块，所以余额变成了110,
// 但是这期间如果另一线程取了5块，那余额应该是100-5+10=105，但是这里并没有靠拢100-5，而是很暴力的将110写入到accountBalance
accountBalance = tempValue;

Log.infov("end deposit, balance [{0}]", tempValue);}

/**
 * 模拟了一次扣费操作，
 * 将账号余额读取到本地变量，
 * 经过一秒钟的计算后，将计算结果写入账号余额，
 * 这一秒内，如果账号余额发生了变化，就会被此方法的本地变量覆盖，
 * 因此，多线程的时候，如果其他线程修改了余额，那么这里就会覆盖掉，导致多线程同步问题，
 * AccountBalanceService类使用了Lock注解后，执行此方法时，其他线程执行AccountBalanceService的方法时就会block住，避免了多线程同步问题
 * @param value
 * @throws InterruptedException
 */
public void deduct(int value) {
    // 先将accountBalance的值存入tempValue变量
    int tempValue  = accountBalance;
    Log.infov("start deduct, balance [{0}], deposit value [{1}]", tempValue, value);// 模拟耗时的操作
try {
    Thread.sleep(100);
} catch (InterruptedException e) {
    e.printStackTrace();
}

tempValue -= value;

// 用tempValue的值覆盖accountBalance，
// 这个tempValue的值是基于100毫秒前的accountBalance计算出来的，
// 如果这100毫秒期间其他线程修改了accountBalance，就会导致accountBalance不准确的问题
// 例如最初有100块，这里存了10块，所以余额变成了110,
// 但是这期间如果另一线程取了5块，那余额应该是100-5+10=105，但是这里并没有靠拢100-5，而是很暴力的将110写入到accountBalance
accountBalance = tempValue;

Log.infov("end deduct, balance [{0}]", tempValue);
}

}

接下来是单元测试类LockTest.java，有几处需要注意的地方稍后会说明

package com.bolingcavalry;

import com.bolingcavalry.service.impl.AccountBalanceService;
import io.quarkus.logging.Log;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

import javax.inject.Inject;
import java.util.concurrent.CountDownLatch;

@QuarkusTest
public class LockTest {

@Inject
AccountBalanceService account;

@Test
public void test() throws InterruptedException {
    CountDownLatch latch = new CountDownLatch(3);
    int initValue = account.get();final int COUNT = 10;

// 这是个只负责读取的线程，循环读10次，每读一次就等待50毫秒
new Thread(() -&gt; {

    for (int i=0;i&lt;COUNT;i++) {
        // 读取账号余额
        Log.infov("current balance {0}", account.get());
    }

    latch.countDown();
}).start();

// 这是个充值的线程，循环充10次，每次存2元
new Thread(() -&gt; {
    for (int i=0;i&lt;COUNT;i++) {
        account.deposit(2);
    }
    latch.countDown();
}).start();

// 这是个扣费的线程，循环扣10次，每取1元
new Thread(() -&gt; {
    for (int i=0;i&lt;COUNT;i++) {
        account.deduct(1);
    }
    latch.countDown();
}).start();

latch.await();

int finalValue = account.get();
Log.infov("finally, current balance {0}", finalValue);
Assertions.assertEquals(initValue + COUNT, finalValue);
}

}

上述代码中，有以下几点需要注意

在主线程中新增了三个子线程，分别执行查询、充值、扣费的操作，可见deposit和deduct方法是并行执行的
初始余额100，充值一共20元，扣费一共10元，因此最终正确结果应该是110元
为了确保三个子线程全部执行完毕后主线程才退出，这里用了CountDownLatch，在执行latch.await()的时候主线程就开始等待了，等到三个子线程把各自的latch.await()都执行后，主线程才会继续执行
最终会检查余额是否等于110，如果不是则单元测试不通过

执行单元测试，结果如下图，果然失败了

来分析测试过程中的日志，有助于我们理解问题的原因，如下图，充值和扣费同时开始，充值先完成，此时余额是102，但是扣费无视102，依旧使用100作为余额去扣费，然后将扣费结果99写入余额，导致余额与正确的逻辑产生差距

反复运行上述单元测试，可以发现每次得到的结果都不一样，这算是典型的多线程同步问题了吧…
看到这里，经验丰富的您应该想到了多种解决方式，例如下面这五种都可以：

用传统的synchronized关键字修饰三个方法
java包的读写锁
deposit和deduct方法内部，不要使用临时变量tempValue，将余额的类型从int改成AtomicInteger，再使用addAndGet方法计算并设置
用MySQL的乐观锁
用Redis的分布式锁

没错，上述方法都能解决问题，现在除了这些，quarku还从bean的维度为我们提供了一种新的方法：bean读写锁，接下来细看这个bean读写锁

Container-managed Concurrency：quarkus基于bean的读写锁方案

quarkus为bean提供了读写锁方案：Lock注解，借助它，可以为bean的所有方法添加同一把写锁，再手动将读锁添加到指定的读方法，这样在多线程操作的场景下，也能保证数据的正确性

来看看Lock注解源码，很简单的几个属性，要重点注意的是：默认属性为Type.WRITE，也就是写锁，被Lock修饰后，锁类型有三种选择：读锁，写锁，无锁

@InterceptorBinding
@Inherited
@Target(value = { TYPE, METHOD })
@Retention(value = RUNTIME)
public @interface Lock {

/**
 *
 * @return the type of the lock
 */
@Nonbinding
Type value() default Type.WRITE;

/**
 * If it's not possible to acquire the lock in the given time a {@link LockException} is thrown.
 *
 * @see java.util.concurrent.locks.Lock#tryLock(long, TimeUnit)
 * @return the wait time
 */
@Nonbinding
long time() default -1l;

/**
 *
 * @return the wait time unit
 */
@Nonbinding
TimeUnit unit() default TimeUnit.MILLISECONDS;

public enum Type {
    /**
     * Acquires the read lock before the business method is invoked.
     */
    READ,
    /**
     * Acquires the write (exclusive) lock before the business method is invoked.
     */
    WRITE,
    /**
     * Acquires no lock.
     * <p>
     * This could be useful if you need to override the behavior defined by a class-level interceptor binding.
     */
    NONE
}

}

接下来看看如何用bean锁解AccountBalanceService的多线程同步问题
为bean设置读写锁很简单，如下图红框1，给类添加Lock注解后，AccountBalanceService的每个方法都默认添加了写锁，如果想修改某个方法的锁类型，可以像红框2那样指定，Lock.Type.READ表示将get方法改为读锁，如果不想给方法上任何锁，就使用Lock.Type.NONE

这里预测一下修改后的效果

在deposit和deduct都没有被调用时，get方法可以被调用，而且可以多线程同时调用，因为每个线程都能顺利拿到读锁
一旦deposit或者deduct被调用，其他线程在调用deposit、deduct、get方法时都被阻塞了，因为此刻不论读锁还是写锁都拿不到，必须等deposit执行完毕，它们才重新去抢锁
有了上述逻辑，再也不会出现deposit和deduct同时修改余额的情况了，预测单元测试应该能通过
这种读写锁的方法虽然可以确保逻辑正确，但是代价不小（一个线程执行，其他线程等待），所以在并发性能要求较高的场景下要慎用，可以考虑乐观锁、AtomicInteger这些方式来降低等待代价