使用JPA或Hibernate时，如何实现乐观锁和悲观锁？各自适用的场景是什么？

Question

使用JPA或Hibernate时，如何实现乐观锁和悲观锁？各自适用的场景是什么？

Answer 1

在使用JPA或Hibernate时，实现乐观锁和悲观锁通常依赖于JPA提供的注解或者Hibernate的内置机制。以下是两种锁机制的实现方法及其适用场景：
乐观锁

实现方法： 在JPA或Hibernate中，乐观锁最常见的是通过@Version注解实现。在实体类中添加一个版本字段（通常是整型），并用@Version注解标记。当一个事务尝试更新该实体时，Hibernate会自动检查版本字段：

更新前：查询时带上当前版本信息。
更新时：在SQL更新语句中加入版本检查条件，如version = :currentVersion AND ...。
提交时：如果数据库中对应的记录版本与查询时获取的版本一致，则更新成功并递增版本；若版本不一致（即有其他事务已更新过该记录），则更新失败，抛出OptimisticLockException。

例如：

java

@Entity

class MyEntity {

@Id

private Long id;


@Version

private int version; // 自动维护的乐观锁版本字段


// 其他属性、getter/setter...

}

适用场景：

读多写少的场景，尤其是高并发读取，冲突更新较少的情况。
对响应速度要求较高，希望减少因锁等待导致的性能损失。
可接受偶尔的更新冲突并进行重试逻辑处理。

悲观锁

实现方法： 在JPA中，悲观锁通常通过@Lock注解在查询方法上指定，或者在Criteria API、HQL/JPQL查询中使用特定的查询Hint。常用的锁模式包括：

PESSIMISTIC_READ：获取共享锁，允许多个事务同时读取但阻止其他事务写入。
PESSIMISTIC_WRITE：获取排他锁，仅允许当前事务读写，阻止其他事务读写。

例如：

java

public interface MyEntityRepository extends JpaRepository<MyEntity, Long> {

@Lock(LockModeType.PESSIMISTIC_WRITE)

MyEntity findByIdAndLock(Long id);

}

在上述例子中，findByIdAndLock方法会在查询时立即在数据库层面锁定指定ID的MyEntity记录，直到事务结束。

适用场景：

写操作频繁或更新冲突可能性较大的场景。
对数据一致性要求极高，不允许出现任何并发更新冲突。
执行长事务或复杂业务流程，需要确保在事务执行期间数据不变。

结论

选择使用乐观锁还是悲观锁，应根据具体的业务场景和性能要求来决定。乐观锁适用于读多写少、并发冲突较少且对响应速度敏感的情况，而悲观锁适用于写操作频繁、更新冲突可能性大或对数据一致性要求极高的场景。在实际应用中，有时也会结合使用两种锁策略，以应对不同部分业务的需求。