高并发场景下锁的使用技巧

以你之姓@ 2023-03-01 09:22 61阅读 0赞

> 来源：33h.co/dVMB

如何确保一个方法，或者一块代码在高并发情况下，同一时间只能被一个线程执行，单体应用可以使用并发处理相关的 API 进行控制，但单体应用架构演变为分布式微服务架构后，跨进程的实例部署，显然就没办法通过应用层锁的机制来控制并发了。

那么锁都有哪些类型，为什么要使用锁，锁的使用场景有哪些？今天我们来聊一聊高并发场景下锁的使用技巧。

# 锁类别 #

不同的应用场景对锁的要求各不相同，我们先来看下锁都有哪些类别，这些锁之间有什么区别。

*  悲观锁(synchronize)
    
     *  Java 中的重量级锁 synchronize
     *  数据库行锁
 *  乐观锁
    
     *  Java 中的轻量级锁 volatile 和 CAS
     *  数据库版本号
 *  分布式锁(Redis锁)

# 乐观锁 #

就好比说是你是一个生活态度乐观积极向上的人，总是往最好的情况去想，比如你每次去获取共享数据的时候会认为别人不会修改，所以不会上锁，但是在更新的时候你会判断这期间有没有人去更新这个数据。

乐观锁使用在前，判断在后。我们看下伪代码：

reduce()
    {
        select total_amount from table_1
        if(total_amount < amount ){
              return failed.  
        }  
        //其他业务逻辑
        update total_amount = total_amount - amount where total_amount > amount; 
    }

*  数据库的版本号属于乐观锁；
 *  通过CAS算法实现的类属于乐观锁。

# 悲观锁 #

悲观锁是怎么理解呢？相对乐观锁刚好反过来，总是假设最坏的情况，假设你每次拿数据的时候会被其他人修改，所以你在每次共享数据的时候会对他加一把锁，等你使用完了再释放锁，再给别人使用数据。

悲观锁判断在前，使用在后。我们也看下伪代码：

reduce()
    {
        //其他业务逻辑
        int num = update total_amount = total_amount - amount where total_amount > amount; 
    　　 if(num ==1 ){
              //业务逻辑.  
        } 
    }

*  Java中的的synchronize是重量级锁 ，属于悲观锁；
 *  数据库行锁属于悲观锁；

# 扣减操作案例 #

这里举一个非常常见的例子，在高并发情况下余额扣减，或者类似商品库存扣减，也可以是资金账户的余额扣减。扣减操作会发生什么问题呢？很容易可以看到，可能会发生的问题是**扣减导致的超卖**，也就是扣减成了负数。

举个例子，比如我的库存数据只有100个。并发情况下第1笔请求卖出100个，第2批卖出100元，导致当前的库存数量为负数。遇到这种场景应该如何破解呢？这里列举四种方案。

### **方案1：同步排它锁** ###

这时候很容易想到最简单的方案：**同步排它锁**(synchronize)。但是排他锁的缺点很明显：

*  其中一个缺点是，线程串行导致的性能问题，性能消耗比较大。
 *  另一个缺点是无法解决分布式部署情况下跨进程问题；

### **方案2：数据库行锁** ###

第二我们可能会想到，那用数据库行锁来锁住这条数据，这种方案相比排它锁解决了跨进程的问题，但是依然有缺点。

*  其中一个缺点就是性能问题，在数据库层面会一直阻塞，直到事务提交，这里也是串行执行；
 *  第二个需要注意设置事务的隔离级别是Read Committed，否则并发情况下，另外的事务无法看到提交的数据，依然会导致超卖问题；
 *  缺点三是容易打满数据库连接，如果事务中有第三方接口交互(存在超时的可能性)，会导致这个事务的连接一直阻塞，打满数据库连接。
 *  最后一个缺点，容易产生交叉死锁，如果多个业务的加锁控制不好，就会发生AB两条记录的交叉死锁。

### **方案3：redis分布式锁** ###

前面的方案本质上是把数据库当作分布式锁来使用，所以同样的道理，redis，zookeeper都相当于数据库的一种锁。

其实当遇到加锁问题，代码本身无论是synchronize或者各种lock使用起来都比较复杂，所以思路是把代码处理一致性的问难题交给一个能够帮助你处理一致性的问题的专业组件，比如数据库，比如redis，比如zookeeper等。

这里我们分析下分布式锁的优缺点：

*  优点：
    
     *  可以**避免大量对数据库排他锁的征用，提高系统的响应能力；**
 *  缺点：
    
     *  设置锁和设置超时时间的原子性；
     *  不设置超时时间的缺点；
     *  服务宕机或线程阻塞超时的情况；
     *  超时时间设置不合理的情况；

**加锁和过期设置的原子性**

redis加锁的命令setnx，设置锁的过期时间是expire，解锁的命令是del，但是2.6.12之前的版本中，加锁和设置锁过期命令是两个操作，不具备原子性。

如果setnx设置完key-value之后，还没有来得及使用expire来设置过期时间，当前线程挂掉了或者线程阻塞，会导致当前线程设置的key一直有效，后续的线程无法正常使用setnx获取锁，导致死锁。

针对这个问题，redis2.6.12以上的版本增加了可选的参数，可以在加锁的同时设置key的过期时间，保证了加锁和过期操作原子性的。

但是，即使解决了原子性的问题，业务上同样会遇到一些极端的问题，比如分布式环境下，A获取到了锁之后，因为线程A的业务代码耗时过长，导致锁的超时时间，锁自动失效。

后续线程B就意外的持有了锁，之后线程A再次恢复执行，直接用del命令释放锁，这样就错误的将线程B同样Key的锁误删除了。代码耗时过长还是比较常见的场景，假如你的代码中有外部通讯接口调用，就容易产生这样的场景。

**设置合理的时长**

刚才讲到的线程超时阻塞的情况，那么如果不设置时长呢，当然也不行，如果线程持有锁的过程中突然服务宕机了，这样锁就永远无法失效了。

同样的也存在锁超时时间设置是否合理的问题，如果设置所持有时间过长会影响性能，如果设置时间过短，有可能业务阻塞没有处理完成，是否可以合理的设置锁的时间?

**续命锁**

这是一个很不容易解决的问题，不过有一个办法能解决这个问题，那就是续命锁，我们可以先给锁设置一个超时时间，然后启动一个守护线程，让守护线程在一段时间之后重新去设置这个锁的超时时间。

续命锁的实现过程就是写一个守护线程，然后去判断对象锁的情况，快失效的时候，再次进行重新加锁，但是一定要判断锁的对象是同一个，不能乱续。

同样，主线程业务执行完了，守护线程也需要销毁，避免资源浪费，使用续命锁的方案相对比较而言更复杂，所以如果业务比较简单，可以根据经验类比，合理的设置锁的超时时间就行。

### **方案4：数据库乐观锁** ###

数据库乐观锁加锁的一个原则就是尽量想办法减少锁的范围。锁的范围越大，性能越差，数据库的锁就是把锁的范围减小到了最小。我们看下面的伪代码

reduce()
    {
        select total_amount from table_1
        if(total_amount < amount ){
              return failed.  
        }  
        //其他业务逻辑
        update total_amount = total_amount - amount;  
    }

我们可以看到修改前的代码是没有where条件的。修改后，再加where条件判断：总库存大于将被扣减的库存。

update total_amount = total_amount - amount where total_amount > amount

如果更新条数返回0，说明在执行过程中被其他线程抢先执行扣减，并且避免了扣减为负数。

但是这种方案还会涉及一个问题，如果在之前的update代码中，以及其他的业务逻辑中还有一些其他的数据库写操作的话，那这部分数据如何回滚呢？

我的建议是这样的，你可以选择下面这两种写法：

*  利用事务回滚写法：

我们先给业务方法增加事务，方法在扣减库存影响条数为零的时候扔出一个异常，这样对他之前的业务代码也会回滚。

reduce()
    {
        select total_amount from table_1
        if(total_amount < amount ){
              return failed.  
        }  
        //其他业务逻辑
        int num = update total_amount = total_amount - amount where total_amount > amount; 
    　　if(num==0) throw Exception;
    }

*  第二种写法

reduce()
    {
        //其他业务逻辑
        int num = update total_amount = total_amount - amount where total_amount > amount; 
    　　 if(num ==1 ){
              //业务逻辑.  
        }  else{
    　　　　throw Exception;
    　　}
    }

首先执行update业务逻辑，如果执行成功了再去执行逻辑操作，这种方案是我相对比较建议的方案。

在并发情况下对共享资源扣减操作可以使用这种方法，但是这里需要引出一个问题，比如说万一其他业务逻辑中的业务，因为特殊原因失败了该怎么办呢？比如说在扣减过程中服务OOM了怎么办？

我只能说这些非常极端的情况，比如突然宕机中间数据都丢了，这种极少数的情况下只能人工介入，如果所有的极端情况都考虑到，也不现实。我们讨论的重点是并发情况下，共享资源的操作如何加锁的问题。

# 总结 #

最后我来给你总结一下，如果你可以非常熟练的解决这类问题，第一时间肯定想到的是：数据库版本号解决方案或者分布式锁的解决方案；但是如果你是一个初学者，相信你一定会第一时间考虑到Java中提供的同步锁或者数据库行锁。

今天讨论的目的就是希望把这几种场景中的锁放到一个具体的场景中，逐步去对比和分析，让你能够更加全面体系的了解使用锁这个问题的来龙去脉。我是张飞洪，希望我的分享可以帮助到你。