悲观锁和乐观锁是两种常见的并发控制机制，用于处理多线程或多进程环境中的数据访问冲突问题。它们在数据库系统、分布式系统和多线程编程中都有广泛应用。这篇文章我们来分析它们的原理以及使用场景。
一、悲观锁1.定义悲观锁（Pessimistic Lock）是一种假设冲突会频繁发生的锁机制。每次数据访问时，都会先加锁，直到操作完成后才释放锁，这样可以确保在锁持有期间，其他线程无法访问这段数据，从而避免了并发冲突。
悲观锁的实现通常有以下两种方式：
数据库：在数据库中，悲观锁通常通过SQL语句实现，例如SELECT ... FOR UPDATE。编程语言：在编程语言中，悲观锁可以使用互斥锁（Mutex）或同步块（Synchronized Block）来实现。2.应用场景适用于对数据并发冲突非常敏感的场景，例如银行转账操作、库存扣减等需要严格数据一致性的操作。
3.优缺点优点：可以完全避免并发冲突，保证数据的一致性和完整性。缺点：由于每次访问数据都需要加锁和解锁，会导致性能开销较大，特别是在并发量高的情况下，容易造成锁竞争和死锁问题。4.示例下面我们用 Java + MySQL 展示了一个悲观锁的具体实现。
假设有一个银行账户表（Account），包含账户 ID和余额两个字段，我们希望在更新账户余额时使用悲观锁，以确保数据的一致性。
整个运行流程分为以下4个步骤：
获取账户信息并锁定记录（SELECT ... FOR UPDATE）。计算新的余额。更新账户信息。由于使用了@Transactional注解，整个方法执行在一个事务中，确保在事务提交之前，锁定的记录不会被其他事务修改。(1) 数据库表结构
复制
CREATE TABLE Account ( id INT PRIMARY KEY, balance DECIMAL(10, 2) NOT NULL);1.2.3.4.(2) Java实现示例
Account类：
复制
public Account { private int id; private BigDecimal balance; // Getters and Setters}1.2.3.4.5.6.AccountMapper接口：
复制
public interface AccountMapper { Account getAccountByIdForUpdate(int id); void updateAccount(Account account);}1.2.3.4.AccountMapper的SQL实现：
复制
<mapper namespace="com.example.AccountMapper"> <select id="getAccountByIdForUpdate" resultType="com.example.Account"> SELECT id, balance FROM Account WHERE id = #{id} FOR UPDATE </select> <update id="updateAccount"> UPDATE Account SET balance = #{balance} WHERE id = #{id} </update></mapper>1.2.3.4.5.6.7.8.9.10.11.AccountService类：
复制
import org.springframework.transaction.annotation.Transactional;public AccountService { private AccountMapper accountMapper; public AccountService(AccountMapper accountMapper) { this.accountMapper = accountMapper; } @Transactional public void updateAccountBalance(int accountId, BigDecimal amount) { // 获取账户信息并锁定记录 Account account = accountMapper.getAccountByIdForUpdate(accountId); if (account == null) { throw new RuntimeException("Account not found"); } // 更新余额 account.setBalance(account.getBalance().add(amount)); // 更新账户信息 accountMapper.updateAccount(account); }}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.示例说明：
Account类：包含账户ID和余额的Java类。AccountMapper接口：定义了获取账户信息（带锁定）和更新账户信息的方法。AccountMapper的SQL实现：使用MyBatis或其他ORM框架，定义了SQL查询和更新语句。注意在查询语句中使用FOR UPDATE来锁定记录。AccountService类：业务逻辑类，在更新账户余额时，先获取当前账户信息并锁定记录，然后更新余额并提交更新。这种机制确保了在操作完成之前，其他线程无法修改锁定的记录，从而实现了悲观锁的并发控制。
(3) 注意事项
事务管理：使用悲观锁时，需要确保在事务提交之前锁不会被释放，因此必须在事务中使用。死锁风险：悲观锁可能会导致死锁，需要特别注意死锁检测和处理。性能影响：由于每次操作都需要加锁和解锁，性能可能会受到影响，特别是在高并发情况下。通过了解悲观锁的具体实现，可以在需要严格数据一致性的场景中有效地避免并发冲突。
二、乐观锁1.定义乐观锁（Optimistic Lock）是一种假设冲突不会频繁发生的锁机制。每次数据访问时，不会加锁，而是在更新数据时检查是否有其他线程修改过数据。如果检测到冲突（数据被其他线程修改过），则重试操作或报错。
乐观锁通常实现方式有以下两种：
版本号机制：每次读取数据时，读取一个版本号，更新数据时，检查版本号是否变化，如果没有变化，则更新成功，否则重试。时间戳机制：类似版本号机制，通过时间戳来检测数据是否被修改。2.应用场景适用于读多写少的场景，例如用户评论系统、社交媒体点赞等，这些场景下并发冲突概率较低。
3.优缺点优点：避免了频繁的锁操作，性能较好，适合读多写少的场景。缺点：在高并发写操作的场景下，重试可能会频繁发生，导致性能下降。4.示例乐观锁的实现通常涉及到版本号（或时间戳）机制，以便在更新数据时检测是否发生了并发修改。我们还是用上面的示例，展示了如何在 Java中使用乐观锁进行并发控制。
假设有一个银行账户表（Account），包含账户ID、余额和版本号三个字段，现在希望在更新账户余额时使用乐观锁，以确保数据的一致性。
整个运行流程总结为下面 3个步骤：
获取账户信息，包括当前的版本号。计算新的余额，并增加版本号。尝试更新账户信息，如果版本号匹配则更新成功，否则更新失败并抛出异常。(1) 数据库表结构
复制
CREATE TABLE Account ( id INT PRIMARY KEY, balance DECIMAL(10, 2) NOT NULL, version INT NOT NULL);1.2.3.4.5.(2) Java实现示例
Account类：
复制
public Account { private int id; private BigDecimal balance; private int version; // Getters and Setters}1.2.3.4.5.6.7.AccountMapper接口：
复制
public interface AccountMapper { Account getAccountById(int id); int updateAccount(Account account);}1.2.3.4.AccountMapper的SQL实现：
复制
<mapper namespace="com.example.AccountMapper"> <select id="getAccountById" resultType="com.example.Account"> SELECT id, balance, version FROM Account WHERE id = #{id} </select> <update id="updateAccount"> UPDATE Account SET balance = #{balance}, version = #{version} WHERE id = #{id} AND version = #{oldVersion} </update></mapper>1.2.3.4.5.6.7.8.9.10.11.AccountService类：
复制
public AccountService { private AccountMapper accountMapper; public AccountService(AccountMapper accountMapper) { this.accountMapper = accountMapper; } public void updateAccountBalance(int accountId, BigDecimal amount) { // 获取账户信息 Account account = accountMapper.getAccountById(accountId); if (account == null) { throw new RuntimeException("Account not found"); } // 记录当前版本号 int currentVersion = account.getVersion(); // 更新余额 account.setBalance(account.getBalance().add(amount)); // 更新版本号 account.setVersion(currentVersion + 1); // 尝试更新账户信息 int updatedRows = accountMapper.updateAccount(account); if (updatedRows == 0) { // 更新失败，可能是由于并发修改导致的版本号不匹配 throw new OptimisticLockException("Update failed due to concurrent modification"); } }}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.示例说明：
Account类：包含账户ID、余额和版本号的Java类。AccountMapper接口：定义了获取账户信息和更新账户信息的方法。AccountMapper的SQL实现：使用MyBatis或其他ORM框架，定义了SQL查询和更新语句。注意在更新语句中使用了旧版本号来检测并发修改。AccountService类：业务逻辑类，在更新账户余额时，先获取当前账户信息及其版本号，然后尝试更新余额和版本号。如果更新失败，抛出一个OptimisticLockException。三、区别总结假设前提：
悲观锁假设冲突会频繁发生，需要加锁保护。乐观锁假设冲突不会频繁发生，通过版本号或时间戳来检测冲突。性能：
悲观锁性能较低，因为每次操作都需要加锁和解锁。乐观锁性能较高，但在高并发写操作下可能会频繁重试，影响性能。应用场景：
悲观锁适用于并发冲突高、数据一致性要求严格的场景。乐观锁适用于并发冲突低、读多写少的场景。四、总结本文我们详细分析了悲观锁和乐观锁的原理、区别、实现方式和应用场景，实际工作中，可以根据具体需求选择合适的并发控制机制，以保证系统的性能和数据一致性。
更多资讯，点击
