乐观锁详解：如何处理高并发下的数据一致性问题

创作时间:

作者:

@小白创作中心

乐观锁详解：如何处理高并发下的数据一致性问题

引用

CSDN

https://blog.csdn.net/qq254606826/article/details/143031407

在现代应用程序中，特别是在高并发场景下，确保数据一致性是一项重要任务。乐观锁（Optimistic Locking）作为一种有效的并发控制机制，允许多个事务并发地读取相同的数据，而不立即加锁。本文将详细探讨乐观锁的原理、实现方法以及其应用场景，并结合实际示例和相关内容进行讲解。

乐观锁的基本原理

乐观锁的核心思想是“冲突检测”。在数据被修改之前，不对数据加锁。相反，当事务尝试提交时，乐观锁会检测是否有其他事务修改了同一数据。如果检测到冲突，则会回滚事务并提示用户重试操作。这种机制减少了对资源的占用，提高了系统的并发性能。

丢失更新问题

在高并发环境中，丢失更新问题是一个常见的挑战。丢失更新问题发生在两个或多个事务并发地读取和更新相同的数据时。具体来说，如果两个事务读取了相同的数据并分别对其进行更新，后提交的事务可能会覆盖先提交的事务的更改，从而导致数据的部分更新被丢失。

在上图中，假设 Alice 和 Bob 同时尝试从账户中取款。Alice 读取了账户余额为 50 元，并打算取款 40 元。与此同时，Bob 也读取了账户余额为 50 元，并打算取款 30 元。由于没有任何锁机制，Alice 和 Bob 的操作可以并行进行，Alice 认为她可以从账户中提取 40 元，但她没有意识到 Bob 刚刚更改了账户余额，现在账户中只有 20 元，最终可能导致账户余额被错误地更新为 -20 元（50 - 70）。

乐观锁与悲观锁的比较

悲观锁通过在读取数据时立即加锁来防止其他事务修改数据。例如，当 Alice 和 Bob 试图同时读取并更新同一个账户时，悲观锁会阻止 Bob 的更新直到 Alice 提交事务。这种方式减少了冲突的可能性，但会导致较高的锁争用和潜在的死锁问题。

以下是悲观锁处理丢失更新问题的过程图示：

在上图中，Alice 和 Bob 都会对读取的账户表行获取读锁。在 SQL Server 上，使用可重复读（Repeatable Read）或序列化（Serializable）隔离级别时，数据库会获取这些锁。

因为 Alice 和 Bob 都读取了具有主键值为 1 的账户，所以他们中的任何一个在释放读锁之前都不能更改它。这是因为写操作需要获取写锁/排他锁，而读锁/共享锁会阻止获取写锁/排他锁。

只有在 Alice 提交事务并释放账户行上的读锁后，Bob 的 UPDATE 操作才能继续并应用更改。在 Alice 释放读锁之前，Bob 的 UPDATE 操作会被阻塞。

乐观锁则不同，它在读取数据时不加锁，只在更新时检查数据版本是否一致。如果版本一致，则更新成功；否则，更新失败并提示用户重试。这种机制减少了锁的使用，提高了系统的并发性能，但可能会导致更多的事务回滚和重试。

应用级事务

在某些场景下，单个数据库事务可能无法满足业务需求，需要跨多个数据库操作或服务调用。在这种情况下，可以使用应用级事务来实现更复杂的事务逻辑。应用级事务通常使用分布式事务协议（如两阶段提交）或补偿事务来保证数据一致性。

实现乐观锁的示例代码

在实际应用中，乐观锁通常通过版本号或时间戳来实现。以下是一个使用版本号实现乐观锁的示例代码：

public class Account {
    private Long id;
    private String accountNumber;
    private BigDecimal balance;
    private Integer version;

    // getters and setters
}

@Repository
public interface AccountRepository extends JpaRepository<Account, Long> {
    @Modifying
    @Query("UPDATE Account a SET a.balance = :newBalance, a.version = a.version + 1 WHERE a.id = :id AND a.version = :version")
    int updateBalance(@Param("id") Long id, @Param("newBalance") BigDecimal newBalance, @Param("version") Integer version);
}

@Service
public class AccountService {
    @Autowired
    private AccountRepository accountRepository;

    public void updateBalance(Long id, BigDecimal newBalance) {
        Account account = accountRepository.findById(id).orElseThrow(() -> new RuntimeException("Account not found"));
        int rowsAffected = accountRepository.updateBalance(id, newBalance, account.getVersion());
        if (rowsAffected == 0) {
            throw new OptimisticLockException("Optimistic lock exception");
        }
    }
}

在这个示例中，Account实体包含一个版本号字段。在更新账户余额时，会检查版本号是否匹配。如果不匹配，则说明数据已被其他事务修改，更新操作将失败。