SpringBoot JPA不使用Repository层@Lock注解如何实现表级锁

直接用数据库原生表级写锁就能满足需求，不需要额外引入组件，完全适配你现有的SpringBoot+JPA+JdbcTemplate技术栈，也能覆盖B方法里禁用/启用表约束的场景——表级写锁会阻塞所有其他会话对目标表的写操作，从数据库层面保证互斥，比JVM层面的锁适配多实例部署场景，比JPA自带的@Lock行锁粒度更匹配你要做表约束变更的需求。

具体实现逻辑 #

1. 基础配置校验 #

给服务层的A、B两个方法都加上@Transactional注解，保证两个方法的所有数据库操作都在Spring托管的事务上下文里执行，数据库锁的生命周期会和事务完全绑定，事务提交/回滚时锁会自动释放，避免死锁。

注意不要把加锁逻辑写在事务边界外，否则加锁语句执行完连接归还连接池后锁会立刻失效，完全起不到互斥作用。

2. 改造B方法的加锁逻辑 #

在B方法的业务逻辑最开头，直接用已经注入的JdbcTemplate执行数据库的表加锁语句，根据你用的数据库选对应的语法即可：

• 如果使用MySQL，核心代码示例：

@Transactional
public void B() {
    // 申请表T的写锁，语句执行完成后，其他所有会话对T的写请求都会阻塞
    jdbcTemplate.execute("LOCK TABLES T WRITE");
    try {
        // 原有业务逻辑：禁用表T的约束
        // 原有业务逻辑：执行表T的更新操作
        // 原有业务逻辑：重新启用表T的约束
    } finally {
        // 主动释放锁做兜底，事务提交时锁也会自动释放，双重保障避免锁残留
        jdbcTemplate.execute("UNLOCK TABLES");
    }
}

• 如果使用PostgreSQL，核心代码示例：

@Transactional
public void B() {
    // PG的ACCESS EXCLUSIVE模式锁会阻塞所有其他对表的写访问，和MySQL WRITE锁效果一致
    jdbcTemplate.execute("LOCK TABLE T IN ACCESS EXCLUSIVE MODE");
    // 原有业务逻辑：禁用表T的约束
    // 原有业务逻辑：执行表T的更新操作
    // 原有业务逻辑：重新启用表T的约束
    // PG不需要手动释放锁，事务结束时锁会自动回收
}

3. A方法不需要额外改造 #

A方法里原有更新表T的逻辑完全不用改：当B持有表T的写锁时，A方法里的更新SQL会被数据库直接阻塞，直到B的事务提交、锁释放后才会继续执行，完全符合“B执行期间A请求阻塞等待”的业务要求。

避坑说明 #

• 不要在持有表锁的逻辑块里执行非数据库相关的慢操作，比如调用第三方接口、做大量内存计算，这类操作会拉长锁的持有时间，阻塞所有对表T的写请求，拖慢接口响应，这类逻辑尽量挪到加锁前或者锁释放后执行。
• 不需要额外用synchronized、ReentrantLock这类JVM本地锁，这类锁只能在单服务实例内生效，如果服务做了多实例部署，跨实例的请求无法被拦截，数据库层面的锁对所有连接到库的实例都生效，可靠性更高。
• 如果用MySQL的表锁，注意不要在加锁后操作其他没加锁的表，会直接抛出SQL异常，持锁期间只操作表T即可。

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