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

Question

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

Answer 1

在使用JPA（Java Persistence API）或其常用实现Hibernate进行数据持久化时，可以利用它们提供的机制实现乐观锁和悲观锁。这两种锁机制适用于不同的并发场景，旨在确保在多线程或分布式环境中对数据进行并发访问时的正确性和一致性。

实现乐观锁：

乐观锁基于假设大多数情况下数据在被读取到被更新这段时间内不会发生冲突，因此在读取时不立即加锁，而是在更新时检查数据是否已被其他事务修改。在JPA中，通常通过在实体类中添加一个带有@Version注解的字段来实现乐观锁。这个字段通常是一个整数类型，每次成功更新实体时都会自动递增。

实现步骤：

添加版本字段：在实体类中添加一个整数类型的字段（如Integer version），并用@Version注解标记。

java

@Entity

public class MyEntity {

@Id

@GeneratedValue(strategy = GenerationType.IDENTITY)

private Long id;


// 其他属性...


@Version

private Integer version;


// 构造函数、getter/setter...

}

进行更新操作：当执行更新操作（如EntityManager.merge()或CrudRepository.save()）时，JPA会在提交事务时检查当前版本与数据库中的版本是否一致。如果一致，则更新数据并递增版本号；如果不一致（即数据已被其他事务修改），则抛出OptimisticLockException，提示乐观锁冲突。

java

@Transactional

public void updateEntity(Long id, MyEntity updatedEntity) {

MyEntity entity = entityManager.find(MyEntity.class, id);

// 更新entity的某些属性...

try {

    entityManager.merge(entity);  // 或 repository.save(entity)

} catch (OptimisticLockException e) {

    // 处理乐观锁冲突，如提示用户数据已被修改，需要刷新页面或重试

}

}

适用场景：

乐观锁适用于冲突较少、读多写少的场景，可以减少锁竞争，提高系统并发性能。
适用于数据争抢不激烈、冲突概率较低的业务场景，如内容管理系统、用户资料更新等。

实现悲观锁：

悲观锁采取保守策略，认为在数据处理期间很可能发生冲突，所以在数据读取时就立即加锁，阻止其他事务对该数据进行修改，直到当前事务结束释放锁。

实现步骤：

使用@Lock注解：在查询方法上使用@Lock(LockModeType.PESSIMISTIC_WRITE)注解，执行查询时立即获取悲观写锁。

java

@Query("SELECT e FROM MyEntity e WHERE e.id = :id")

@Lock(LockModeType.PESSIMISTIC_WRITE)

MyEntity findByIdForUpdate(@Param("id") Long id);

或者在entityManager级别使用entityManager.lock(entity, LockModeType.PESSIMISTIC_WRITE)方法。

执行更新操作：在持有锁期间进行数据更新，一旦事务提交，锁自动释放。

适用场景：

悲观锁适用于冲突较多、写操作频繁或对数据一致性要求极高的场景，如金融交易、库存扣减等。
当业务场景中数据争抢严重，一旦发生并发修改可能导致严重后果时，应使用悲观锁确保数据操作的独占性。

总结来说，选择使用乐观锁还是悲观锁，需要根据实际业务场景对数据并发访问的特性、对数据一致性的要求以及对系统性能的影响来综合判断。乐观锁适用于冲突较少、追求高并发性能的场景，而悲观锁适用于冲突较多、对数据完整性和一致性要求严格的场景。