乐观锁与悲观锁：高并发场景下的选择

19年之后由于某些原因断更了三年，23年重新扬帆起航，推出更多优质博文，希望大家多多支持～
古之立大事者，不惟有超世之才，亦必有坚忍不拔之志
个人CSND主页——Micro麦可乐的博客
《Docker实操教程》专栏以最新的Centos版本为基础进行Docker实操教程，入门到实战
《RabbitMQ》本专栏主要介绍使用JAVA开发RabbitMQ的系列教程，从基础知识到项目实战
《设计模式》专栏以实际的生活场景为案例进行讲解，让大家对设计模式有一个更清晰的理解
如果文章能够给大家带来一定的帮助！欢迎关注、评论互动～

前言

在面对高并发的场景下，选择合适的锁策略对于保障数据一致性和提高系统性能至关重要。本文将深入探讨乐观锁和悲观锁两种常见的锁机制，分析它们在高并发环境中的优劣势，以便更好地选择适用于不同场景的锁策略。

乐观锁

原理

乐观锁假设冲突的概率较低，因此在大部分情况下不加锁，而是在更新操作时检查在此期间是否有其他事务对数据进行了修改。最常见的实现方式是使用版本号机制，每次更新都伴随着版本号的增加

优势

• 无阻塞： 乐观锁不会阻塞其他事务的读写操作，因此在读多写少的场景下性能较好。
• 无死锁： 由于不加锁，不存在死锁的风险。

劣势

• 冲突处理： 当多个事务冲突时，需要有一套机制来处理这种冲突，通常是通过重试或回滚事务。

悲观锁

原理

悲观锁认为冲突的概率较高，因此在对数据进行操作前先加锁，以防止其他事务的干扰。典型的实现包括数据库的行级锁和排他锁。

优势

• 冲突处理简单： 由于加锁操作，不需要额外的冲突处理机制。
• 适用于写多读少： 在写多读少的场景下，悲观锁的性能较为可观。

劣势

• 阻塞： 加锁会导致其他事务在获取锁之前阻塞，影响并发性能。
• 死锁风险： 使用悲观锁时，存在死锁的风险，需要合理设计事务流程来避免。

选择锁的依据

1、并发度

高并发读写场景： 乐观锁更适合高并发读写场景，因为不加锁的特性使得读操作不受阻塞。
写多读少场景： 悲观锁在写多读少的场景下更具优势，因为写操作需要确保数据的一致性。

2、数据冲突概率

低冲突概率： 如果数据冲突的概率较低，可以考虑乐观锁。
高冲突概率： 如果数据冲突概率较高，悲观锁更为合适。

3、复杂度

处理复杂度： 乐观锁在处理冲突时相对较为复杂，需要一定的重试和回滚机制。
简单性： 悲观锁在处理冲突时较为简单，加锁即可。

结语

在实际应用中，乐观锁和悲观锁都有其适用的场景，选择应根据具体业务需求和并发访问的特点。在读多写少的情况下，乐观锁可以更好地发挥其性能优势；而在写多读少的情况下，悲观锁则更为适用。合理选择锁策略是高并发系统设计的关键一环，需要充分考虑业务场景和系统特性