现在我们简单聊一下数据库中的悲观锁和乐观锁。
悲观锁
场景: 同学A和同学B都要给你转500块钱(开心坏了吧，这样最终你能得到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。这一定是不能接受的吧。
丢失的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 and version = 0。(此时版本号为0，所以更新成功) - 同学B转账完成
update table set balance = ${balance}, version = version + 1 and version = 0。(此时版本号为1，所以更新失败，更新失败之后同学B再转一次即可) - 同学B重新转帐之后，你还是美滋滋的获得了1000。
总结
悲观锁：读取时加锁，更新完释放锁，再此过程中会造成其他线程阻塞，导致吞吐量低，适用于多写场景。
乐观锁：不加锁，只有在更新时验证数据是否被其他线程更新，吞吐量较高，适用于多读场景。