面试必考：乐观锁与悲观锁的原理与应用

创作时间:

2025-01-21 18:40:33

作者:

@小白创作中心

面试必考：乐观锁与悲观锁的原理与应用

在多线程和分布式系统中，乐观锁和悲观锁是两种常用的并发控制机制。它们各自有着独特的设计理念和适用场景。本文将深入探讨这两种锁的原理、实现方式以及在实际开发中的应用，帮助读者更好地理解和使用这两种重要的并发控制工具。

什么是乐观锁和悲观锁？

在并发控制领域，乐观锁和悲观锁代表了两种截然不同的设计哲学。

悲观锁：假设在并发环境中，总会有其他线程来干扰当前线程的执行，因此在访问共享资源之前，先将其锁定，以保证数据的完整性和正确性。
乐观锁：假设在并发环境中，其他线程很少对同一份数据进行修改，因此在访问共享资源之前，并不会将其锁定。而是在更新数据时，先读取当前版本号，然后进行更新操作，在更新时比较版本号是否一致，如果一致，则更新成功；否则说明有其他线程已经修改了该数据，则需要回滚并重新尝试更新。

悲观锁的实现与特点

悲观锁的实现方式主要是通过数据库中的行级锁、表级锁、读写锁等机制来实现。在数据库系统中，悲观锁通常通过以下方式实现：

行级锁：锁定特定的行，只允许当前事务进行修改。例如，InnoDB存储引擎中的SELECT ... FOR UPDATE语句。
表级锁：锁定整个表，防止其他事务对表进行任何操作。例如，使用LOCK TABLES语句。
读写锁：允许多个读锁同时存在，但写锁是独占的。例如，SELECT ... LOCK IN SHARE MODE。

悲观锁的优点是数据一致性有保障，实现简单。但缺点是性能开销大，容易导致死锁，特别是在高并发场景下。

乐观锁的实现与特点

乐观锁的实现方式通常是在数据表中增加一个版本号或时间戳字段。具体实现步骤如下：

读取数据时，同时读取版本号或时间戳。
更新数据时，检查当前版本号或时间戳是否与读取时一致。
如果一致，更新数据并递增版本号；如果不一致，说明数据已被其他事务修改，需要回滚并重新尝试。

乐观锁的优点是减少了锁的竞争，提高了并发性能，避免了死锁问题。但缺点是在高并发场景下，频繁的CAS操作可能导致性能下降，且需要处理更新失败的情况。

如何选择合适的锁策略？

选择乐观锁还是悲观锁，主要取决于具体的应用场景：

高冲突环境：如银行账户余额更新，适合使用悲观锁。
低冲突环境：如用户信息的更新，适合使用乐观锁。
复杂事务：涉及多个操作的复杂事务，适合使用悲观锁。
高并发环境：需要高并发性能的应用，如Web应用的会话管理，适合使用乐观锁。

实际应用案例

悲观锁应用案例：银行转账系统

在银行转账系统中，由于涉及到资金安全，需要严格保证数据的一致性。当一个事务开始处理转账操作时，需要锁定相关账户，防止其他事务同时修改账户余额。这种场景下，悲观锁是更合适的选择。

START TRANSACTION;
SELECT balance FROM accounts WHERE account_id = 123 FOR UPDATE;
-- 执行转账逻辑
UPDATE accounts SET balance = balance - 100 WHERE account_id = 123;
COMMIT;

乐观锁应用案例：电商平台库存更新

在电商系统中，商品库存的更新是一个典型的并发场景。由于读多写少，且冲突概率较低，使用乐观锁可以提高系统性能。

-- 获取商品库存和版本号
SELECT stock, version FROM products WHERE product_id = 123;

-- 执行业务逻辑...

-- 更新库存时检查版本号是否变化
UPDATE products SET stock = stock - 1, version = version + 1 WHERE product_id = 123 AND version = old_version;