Spring Data JPA中的锁机制

阿乾之铭

于 2024-10-06 11:42:25 发布

阅读量340

点赞数 13

分类专栏： Spring Data JPA 文章标签： spring boot java mysql

本文链接：https://blog.csdn.net/m0_73837751/article/details/142721239

版权

5 篇文章 0 订阅

订阅专栏

当多个事务同时修改同一条记录时，可能会导致数据不一致的问题。为了确保并发事务中的数据一致性，可以使用锁机制。常见的两种锁机制是悲观锁和乐观锁。下面是这两种锁机制的详细讲解。

概念：

悲观锁的核心思想是假设最坏情况，即假设并发事务会发生冲突，因此在读取或修改数据之前，会对数据加锁，阻止其他事务访问该数据，直到当前事务完成。换句话说，悲观锁通过加锁的方式，避免多个事务同时修改同一条记录。

工作原理：

示例：

在JPA中，可以使用@Lock(LockModeType.PESSIMISTIC_WRITE)来实现悲观锁。举个例子：

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT u FROM User u WHERE u.id = :id")
User findUserByIdForUpdate(@Param("id") Long id);

在这个例子中，查询结果中的用户记录会被加锁，其他事务不能同时修改该用户记录，直到当前事务提交或回滚。

优缺点：

适用场景：

悲观锁适用于并发量较小、冲突概率较高的场景。在这种情况下，事务之间的冲突比较容易发生，因此预先加锁可以有效避免数据不一致问题。

概念：

乐观锁的核心思想是假设最好情况，即假设并发事务不会冲突，允许多个事务并发地读取和修改数据。事务提交时，乐观锁会通过版本检查来确保数据的一致性。如果发现数据已经被其他事务修改，则回滚当前事务，以避免数据冲突。

工作原理：

乐观锁通常使用版本号或时间戳来控制并发。例如，每条记录中有一个version字段，每次修改数据时，该字段会递增。
当事务在提交修改时，数据库会检查记录的当前版本号是否与事务开始时读取的版本号一致。如果一致，事务可以提交并更新版本号；如果不一致，说明该记录在此期间已被其他事务修改，当前事务需要回滚或重试。

示例：

在JPA中，可以使用@Version注解来实现乐观锁。例如：

@Entity
public class User {
    @Id
    private Long id;

    private String name;

    @Version
    private Integer version;
}

当事务更新User实体时，JPA会自动检查版本号。如果版本号不匹配，则抛出OptimisticLockException，提示数据已经被其他事务修改。

优缺点：

适用场景：

乐观锁适用于并发量较大但冲突概率较小的场景，例如读操作较多、写操作较少的系统。由于它不会锁定数据，性能相对较高。

悲观锁适合冲突概率较高的场景，如订单系统中，多个用户可能会同时修改同一条记录时。通过预先加锁可以确保事务不冲突，但会影响性能，尤其是在高并发的情况下。
乐观锁适合冲突概率较低的场景，如社交网络中，用户主要是查看信息，更新操作较少。在这种情况下，使用乐观锁可以提供更高的并发性能，并且降低加锁带来的资源开销。