谈谈悲观锁和乐观锁

拼搏现实的明天。 2022-12-19 06:10 116阅读 0赞

我们在软件开发中比较常见的概念，数据库的悲观锁、乐观锁。

**为什么会有这两种锁，主要解决什么问题？** 通常是解决并发读写的问题，用生活中例子就是，上厕所需要上锁，一次只能进1个人，加上锁等方便完后再轮到下一个人得到锁去方便。用在数据库方面的锁，只不过是换了一种技术概念，叫做并发读写的锁。悲观锁，顾名思义，是比较悲观的锁，在写入时认为别人也会同时改写数据，所以会上这种锁，防止别人改写，这种加锁限制比较严格些，导致吞吐量下降，适用于多写少读的场景。乐观锁，顾名思义，是比较乐观的锁，允许多人同时读写数据，只是在最后写入时做一次验证，如发现有不同版本的数据改写时才会限制，如果大多数改写数据不冲突是不会限制的，这比悲观锁的限制要宽松些，数据的吞吐量也比悲观锁要大写，适用于多读少写的场景。我们下面再详细描述一下这两种锁的处理机制、流程方面。

## 悲观锁 ##

**场景**: 同学A和同学B都要给你转500块钱(开心坏了吧，这样最终你能得到1000块钱)。

**使用悲观锁的流程**:

同学A获取到你的账户余额balance = 0并对该条记录加锁。  
同学B获取你的账户余额。由于同学A已经对这条记录加锁了，所以同学B需要等同学A转帐完成(释放锁)才能获得余额。  
同学A转账完成并释放锁，此时你的账户余额balance=balance + 500 = 500  
同学B获取到你的账户余额balance = 500，并对该条记录加锁(如果你人缘好，此时同学C给你转账也是需要等待同学B转账完成才可以转账哦)  
同学B转账完成并释放锁(如果有同学C想给你转账，此时同学C就可以获得锁并转账了)。此时你的账户余额为balance = balance + 500 = 1000  
最终你开开心心的得到了1000块钱。

**假设转账过程没有锁，我们看看会发生什么**:

同学A获取到你的账户余额balance\_a = 0(没有加锁，此时同学B也可以获取到账户余额)  
同学B获取到你的账户余额balance\_b = 0  
同学A转账完成，此时你的账户余额为balance = balance\_a + 500 = 500  
同学B转账完成，此时你的账户余额为balance = balance\_b + 500 = 500  
最终同学A和同学B都转了500，但是你最终只获得了500。这一定是不能接受的吧。

![20201105174336409.png][]

丢失的500块去哪里了呢？从第2步可以看到同学B获取到的账户余额是0，而不是同学A转帐之后的余额500。所以问题出在这里，这是高并发场景的常见问题。所以加锁是非常必须的。但是加了悲观锁，同学都要排队给我转账，对于没有耐心的同学就直接不转帐了，我岂不是错失了发财的好机会。那有什么好办法呢？答案就是下面的乐观锁。

## 乐观锁 ##

**常见的乐观锁实现方式是**：版本号version和CAS(compare and swap)。此处只介绍版本号方式。  
要采用版本号，首先需要在数据库表中新增一个字段version，表示此条记录的更新版本，记录每变动一次，版本号加1。依旧使用上面转账的例子说明：

同学A获取到你的账户余额balance = 0和版本号version\_a = 0  
同学B获取到你的账户余额balance = 0和版本号version\_b = 0  
同学A转账完成update table set balance = $\{balance\}, version = version + 1 where version = 0。(此时版本号为0，所以更新成功)  
同学B转账完成update table set balance = $\{balance\}, version = version + 1 where version = 0。(此时版本号为1，所以更新失败，更新失败之后同学B再转一次即可)  
同学B重新转帐之后，你还是美滋滋的获得了1000。

## 总结 ##

**悲观锁**：读取时加锁，更新完释放锁，再此过程中会造成其他线程阻塞，导致吞吐量低，适用于多写场景。

**乐观锁**：不加锁，只有在更新时验证数据是否被其他线程更新，吞吐量较高，适用于多读场景。

**本文持续改进完善...**

[20201105174336409.png]: /images/20221120/440514c718644cb898637c72903b05e5.png