Hibernate悲观锁和乐观锁

在Hibernate框架中，并发控制是保证数据一致性的重要手段，悲观锁（Pessimistic Locking）和乐观锁（Optimistic Locking）是两种常见的并发控制策略，它们在锁机制、性能表现和适用场景上有显著差异，本文将从原理、实现方式、优缺点及适用场景等方面进行详细对比分析。

悲观锁的原理与实现

1 原理

悲观锁基于“冲突必然发生”的假设，在数据操作前直接锁定资源，阻止其他事务并发修改,其核心是通过数据库或JVM层面的锁机制保证数据一致性。

2 Hibernate实现方式

Hibernate提供多种悲观锁实现方式，主要包括：
| 方法类型 | 说明 |
|——————-|———————————————————————-|
| session.lock() | 通过Hibernate Session的lock()方法显式加锁，支持不同锁模式 |
| Query.setLockMode() | 在HQL查询中设置锁模式，锁定查询结果集 |
| @Lock注解 | 在实体类方法上声明锁模式，结合Spring事务管理使用 |

示例代码：

// 显式加锁
Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
User user = session.get(User.class, 1);
session.lock(user, LockMode.PESSIMISTIC_WRITE); // 写锁
user.setName("newName");
tx.commit();
session.close();

3 锁模式分类

乐观锁的原理与实现

1 原理

乐观锁基于“冲突概率较低”的假设，仅在数据提交时检查冲突，通过版本号或时间戳记录数据状态,若提交时发现版本变化则拒绝操作。

2 Hibernate实现方式

Hibernate主要通过以下两种方式实现乐观锁：
| 实现方式 | 说明 |
|——————-|———————————————————————-|
| @Version注解 | 在实体字段中定义版本号，Hibernate自动维护版本递增 |
| 自定义版本逻辑 | 手动编写版本校验逻辑（不推荐） |

示例代码：

@Entity
public class User {
    @Id(value = 1)
    private Long id;
    @Version // 版本字段必须为整数或长整型
    private Integer version;
    private String name;
}

3 冲突处理机制

当并发修改导致版本不一致时，Hibernate会抛出OptimisticLockException,需通过事务回滚处理。

try {
    tx.commit();
} catch (OptimisticLockException e) {
    tx.rollback();
    // 重试或提示用户冲突
}

悲观锁与乐观锁的对比

适用场景分析

1 悲观锁适用场景

• 高冲突业务：如订单支付、库存扣减等高频修改操作。
• 长时间事务：需保证数据在整个事务期间的一致性。
• 数据库支持：依赖数据库的锁机制（如MySQL InnoDB行级锁）。

2 乐观锁适用场景

• 低冲突业务：如用户信息修改、配置管理等读多写少的场景。
• 高并发环境：允许大量并发读操作,仅个别写操作需校验。
• 简化死锁处理：避免复杂锁关系导致的死锁问题。

常见问题与解决方案

1 如何选择锁策略？

• 优先评估冲突概率：高冲突用悲观锁,低冲突用乐观锁。
• 结合业务特性：长时间事务建议悲观锁,短事务可尝试乐观锁。
• 测试性能：通过压力测试验证锁策略对吞吐量的影响。

2 乐观锁版本冲突如何处理？

• 重试机制：捕获OptimisticLockException后重新执行操作。
• 日志记录：记录冲突日志用于后续分析。
• 用户提示：明确告知用户“数据已被修改，请刷新后重试”。

FAQs

Q1：悲观锁的LockMode.READ和LockMode.WRITE有什么区别？

A1：

• READ模式允许其他事务读取但禁止修改，适合只读操作。
• WRITE模式完全独占资源，禁止其他事务读写，适合修改操作。

  session.lock(entity, LockMode.READ); // 共享读锁  
  session.lock(entity, LockMode.WRITE); // 独占写锁

Q2：乐观锁的版本字段必须是整数吗？

A2：
是的，Hibernate要求@Version字段必须为整数（int/Integer）或长整型（long/Long），因为版本号需要自动递增。

@Version
private Long version; //