JPA为何不允许为Update/Delete操作设置锁？附Hibernate投票实现问题

其实核心原因是JPA的锁机制完全绑定在**持久化上下文（EntityManager管理的实体实例）**上：

• 当你使用@Lock注解时，它的作用是告诉JPA：在把实体加载到内存的持久化上下文时，对数据库对应的行加锁，确保后续对这个实体的修改是线程安全的。
• 但@Modifying标记的Update/Delete操作是直接生成批量SQL发给数据库，完全绕过了持久化上下文——JPA不会加载任何实体实例到内存，自然也就没有可以加锁的目标对象。

JPA规范直接禁止这种无意义的组合，因为锁注解在这类操作上根本起不到作用，反而会造成逻辑混淆，所以干脆不允许这么配置。

你的代码在@Modifying的Update方法上添加@Lock注解，直接违反了JPA规范，Hibernate肯定会抛出类似IllegalArgumentException的异常。下面给你两种可行的解决方案：

方案1：遵循JPA规范的实体操作方式 #

先通过加锁查询加载实体，再修改属性让JPA自动处理更新，这种方式更符合ORM的设计思想：

public interface CrudRestRepository extends Repository<Restaurant, Integer> {

    // 带悲观写锁的查询方法
    Optional<Restaurant> findById(int restId, @Lock(LockModeType.PESSIMISTIC_WRITE));

    // 默认方法实现投票逻辑
    @Transactional
    default void addVoteToRestaurant(int restId) {
        Restaurant restaurant = findById(restId)
                .orElseThrow(() -> new IllegalArgumentException("Restaurant not found with id: " + restId));
        restaurant.setVotes(restaurant.getVotes() + 1);
        // 无需手动save，事务提交时JPA会自动更新脏数据
    }
}

这种方式的优点是代码简洁、完全符合JPA规范，不需要关心底层SQL；缺点是需要加载实体到内存，在极高并发场景下性能略逊于直接SQL操作。

方案2：原生SQL加数据库级锁（高并发推荐） #

如果追求极致性能，可以直接用原生SQL的Update语句，并在语句中添加数据库级别的行锁（比如标准SQL的FOR UPDATE），既能规避JPA规范限制，又能保证并发安全：

public interface CrudRestRepository extends Repository<Restaurant, Integer> {

    @Modifying
    @Transactional
    @Query(value = "UPDATE restaurant SET votes = votes + 1 WHERE id = :restId FOR UPDATE", nativeQuery = true)
    void addVoteToRestaurant(@Param("restId") int restId);
}

这里的FOR UPDATE会让数据库在执行Update时对目标行加悲观写锁，防止其他事务同时修改该行，避免丢失更新的问题。注意：FOR UPDATE是MySQL、PostgreSQL、Oracle等大多数关系型数据库都支持的标准语法，兼容性很强。

为什么这个方案可行？ #

我们直接在SQL层面指定了锁，绕过了JPA的锁注解限制，同时利用数据库本身的锁机制保证了并发安全，非常适合投票这种高并发的计数场景。

内容的提问来源于stack exchange，提问作者Alfred Moon