并发情况如何实现加锁来保证数据一致性？-每日运维

单体架构下锁的实现方案

1. ReentrantLock 全局锁

ReentrantLock（可重入锁），指的是一个线程再次对已持有的锁保护的临界资源时，重入请求将会成功。

简单的与我们常用的 Synchronized 进行比较：

	ReentrantLock	Synchronized
锁实现机制	依赖 AQS	监视器模式
灵活性	支持响应超时、中断、尝试获取锁	不灵活
释放形式	必须显示调用 unlock () 释放锁	自动释放监视器
锁类型	公平锁 & 非公平锁	非公平锁
条件队列	可关联多个条件队列	关联一个条件队列
可重入性	可重入	可重入

AQS 机制：如果被请求的共享资源空闲，那么就当前请求资源的线程设置为有效的工作线程，将共享资源通过 CAScompareAndSetState设置为锁定状态；如果共享资源被占用，就采用一定的阻塞等待唤醒机制（CLH 变体的 FIFO 双端队列）来保证锁分配。

可重入性：无论是公平锁还是非公平锁的情况，加锁过程会利用一个 state 值

private volatile int state

state 值初始化的时候为 0，表示没有任何线程持有锁
当有线程来请求该锁时，state 值会自增 1，同一个线程多次获取锁，就会多次 + 1，这就是可重入的概念
解锁也是对 state 值自减 1，一直到 0，此线程对锁释放。

public class LockExample {

    static int count = 0;
    static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) throws InterruptedException {

        Runnable runnable = new Runnable() {
            @Override
            public void run() {

                try {
                    // 加锁
                    lock.lock();
                    for (int i = 0; i < 10000; i++) {
                        count++;
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
                finally {
                    // 解锁，放在finally子句中，保证锁的释放
                    lock.unlock();
                }
            }
        };

        Thread thread1 = new Thread(runnable);
        Thread thread2 = new Thread(runnable);
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
        System.out.println("count: " + count);
    }
}

/**
 * 输出
 * count: 20000
 */

2. Mysql 行锁、乐观锁

乐观锁即是无锁思想，一般都是基于 CAS 思想实现的，而在 MySQL 中通过 version 版本号 + CAS 无锁形式实现乐观锁；例如 T1，T2 两个事务一起并发执行时，当 T2 事务执行成功提交后，会对 version+1，所以 T1 事务执行的 version 条件就无法成立了。

对 sql 语句进行加锁以及状态机的操作，也可以避免不同线程同时对 count 值访问导致的数据不一致问题。

// 乐观锁 + 状态机
update
    table_name
set
    version = version + 1,
    count = count + 1
where
    id = id AND version = version AND count = [修改前的count值];

// 行锁 + 状态机
 update
    table_name
set
    count = count + 1
where
    id = id AND count = [修改前的count值]
for update;

3. 细粒度的 ReetrantLock 锁

如果我们直接采用 ReentrantLock 全局加锁，那么这种情况是一条线程获取到锁，整个程序全部的线程来到这里都会阻塞；但是我们在项目里面想要针对每个用户在操作的时候实现互斥逻辑，所以我们需要更加细粒度的锁。

public class LockExample {
    private static Map lockMap = new ConcurrentHashMap();
    
    public static void lock(String userId) {
        // Map中添加细粒度的锁资源
        lockMap.putIfAbsent(userId, new ReentrantLock());
        // 从容器中拿锁并实现加锁
        lockMap.get(userId).lock();
    }
    public static void unlock(String userId) {
        // 先从容器中拿锁，确保锁的存在
        Lock locak = lockMap.get(userId);
        // 释放锁
        lock.unlock();
    }
}

弊端：如果每一个用户请求共享资源，就会加锁一次，后续该用户就没有在登录过平台，但是锁对象会一直存在于内存中，这等价于发生了内存泄漏，所以锁的超时和淘汰机制机制需要实现。

4. 细粒度的 Synchronized 全局锁

上面的加锁机制使用到了锁容器ConcurrentHashMap，该容易为了线程安全的情况，多以底层还是会用到Synchronized机制，所以有些情况，使用 lockMap 需要加上两层锁。

那么我们是不是可以直接使用Synchronized来实现细粒度的锁机制

public class LockExample {
    public static void syncFunc1(Long accountId) {
        String lock = new String(accountId + "").intern();

        synchronized (lock) {

            System.out.println(Thread.currentThread().getName() + "拿到锁了");
            // 模拟业务耗时
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            System.out.println(Thread.currentThread().getName() + "释放锁了");
        }
    }

    public static void syncFunc2(Long accountId) {
        String lock = new String(accountId + "").intern();

        synchronized (lock) {

            System.out.println(Thread.currentThread().getName() + "拿到锁了");
            // 模拟业务耗时
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            System.out.println(Thread.currentThread().getName() + "释放锁了");
        }
    }

    // 使用 Synchronized 来实现更加细粒度的锁
    public static void main(String[] args) {
        new Thread(()-> syncFunc1(123456L), "Thread-1").start();
        new Thread(()-> syncFunc2(123456L), "Thread-2").start();
    }
}

/**
 * 打印
 * Thread-1拿到锁了
 * Thread-1释放锁了
 * Thread-2拿到锁了
 * Thread-2释放锁了
 */

从代码中我们发现实现加锁的对象其实就是一个与用户 ID 相关的一个字符串对象，这里可能会有疑问，我每一个新的线程进来，new 的都是一个新的字符串对象，只不过字符串内容一样，怎么能够保证可以安全的锁住共享资源呢；
这其实需要归功于后面的intern()函数的功能；
intern()函数用于在运行时将字符串添加到堆空间中的字符串常量池中，如果字符串已经存在，返回字符串常量池中的引用。

分布式架构下锁的实现方案

核心问题：我们需要找到一个多个进程之间所有线程可见的区域来定义这个互斥量。

一个优秀的分布式锁的实现方案应该满足如下几个特性：

分布式环境下，可以保证不同进程之间的线程互斥
同一时刻，同时只允许一条线程成功获取到锁资源
保证互斥量的地方需要保证高可用性
要保证可以高性能的获取锁和释放锁
可以支持同一线程的锁重入性
具备合理的阻塞机制，竞争锁失败的线程要有相应的处理方案
支持非阻塞式的获取锁。获取锁失败的线程可以直接返回
具备合理的锁失效机制，如超时失效等，可以确保避免死锁情况出现

Redis 实现分布式锁

redis 属于中间件，可独立部署；
对于不同的 Java 进程来说都是可见的，同时性能也非常可观
依赖与 redis 本身提供的指令setnx key value来实现分布式锁；区别于普通set指令的是只有当 key 不存在时才会设置成功，key 存在时会返回设置失败

代码实例：

// 扣库存接口
@RequestMapping("/minusInventory")
public String minusInventory(Inventory inventory) {
    // 获取锁
    String lockKey = "lock-" + inventory.getInventoryId();
    int timeOut = 100;
    Boolean flag = stringRedisTemplate.opsForValue()
            .setIfAbsent(lockKey, "竹子-熊猫",timeOut,TimeUnit.SECONDS);
    // 加上过期时间，可以保证死锁也会在一定时间内释放锁
    stringRedisTemplate.expire(lockKey,timeOut,TimeUnit.SECONDS);
    
    if(!flag){
        // 非阻塞式实现
        return "服务器繁忙...请稍后重试！！！";
    }
    
    // ----只有获取锁成功才能执行下述的减库存业务----        
    try{
        // 查询库存信息
        Inventory inventoryResult =
            inventoryService.selectByPrimaryKey(inventory.getInventoryId());
        
        if (inventoryResult.getShopCount()  0)
        return "端口-" + port + ",库存扣减成功！！！";
    return "端口-" + port + ",库存扣减失败！！！";
}

作者：竹子爱熊猫
链接：https://juejin.cn/post/7038473714970656775

过期时间的合理性分析：

因为对于不同的业务，我们设置的过期时间的长短都会不一样，太长了不合适，太短了也不合适；

所以我们想到的解决方案是设置一条子线程，给当前锁资源续命。具体实现是，子线程间隔 2-3s 去查询一次 key 是否过期，如果还没有过期则代表业务线程还在执行业务，那么则为该 key 的过期时间加上 5s。

但是为了避免主线程意外死亡后，子线程会一直为其续命，造成 “长生锁” 的现象，所以将子线程变为主（业务）线程的守护线程，这样子线程就会跟着主线程一起死亡。

// 续命子线程

public class GuardThread extends Thread {

    private static boolean flag = true;
    public GuardThread(String lockKey,

        int timeOut, StringRedisTemplate stringRedisTemplate){

        ……

    }
    @Override

    public void run() {

        // 开启循环续命

        while (flag){

            try {

                // 先休眠一半的时间

                Thread.sleep(timeOut / 2 * 1000);

            }catch (Exception e){

                e.printStackTrace();

            }

            // 时间过了一半之后再去续命

            // 先查看key是否过期

            Long expire = stringRedisTemplate.getExpire(

                lockKey, TimeUnit.SECONDS);

            // 如果过期了，代表主线程释放了锁

            if (expire

并发情况如何实现加锁来保证数据一致性？

单体架构下锁的实现方案

1. ReentrantLock 全局锁

2. Mysql 行锁、乐观锁

3. 细粒度的 ReetrantLock 锁

4. 细粒度的 Synchronized 全局锁

分布式架构下锁的实现方案

Redis 实现分布式锁

相关文章

发布评论取消回复

捡田螺的小男孩

[20240731]tmux配置使用问题.txt

百度搜索：蓝易云 – gitlab常用命令大全

Oracle 与人才市场平台开展新合作，助力 HR 主管简化招聘、扩展人才库并改善求职者体验

并发情况如何实现加锁来保证数据一致性？

单体架构下锁的实现方案

1. ReentrantLock 全局锁

2. Mysql 行锁、乐观锁

3. 细粒度的 ReetrantLock 锁

4. 细粒度的 Synchronized 全局锁

分布式架构下锁的实现方案

Redis 实现分布式锁

相关文章

发布评论 取消回复

捡田螺的小男孩

[20240731]tmux配置使用问题.txt

百度搜索：蓝易云 – gitlab常用命令大全

Oracle 与人才市场平台开展新合作，助力 HR 主管简化招聘、扩展人才库并改善求职者体验

发布评论取消回复