Hibernate悲观锁实战：LockMode详解与库存超卖解决方案

这是 Hibernate 系列笔记里的第 17 篇，聊的是悲观锁。

做 Java 服务端开发的朋友，只要跟 Hibernate 打过交道，迟早会在并发场景里被同一个问题磨到头痛：库存明明只剩 1 件，两个人几乎同时下单，数据库里却变成了 -1。我第一次排查这种问题时还以为是代码写错了，后来才明白，真正缺的是一个把并发控制下沉到数据库层的机制。这个机制就是 Hibernate 的悲观锁。悲观锁听起来玄乎，其实思路很朴素：我认定这次操作大概率会冲突，所以在事务里先把目标行锁住，等改完提交再放行。它适合正在做订单、库存、余额这类强一致业务的同学，也适合那些用了好几年 Hibernate 却始终没把 LockMode 捋清楚的人。

1. 一个库存超卖场景，把悲观锁的必要性讲清楚

1.1 从两个事务同时扣减库存说起

假设商品表 product 里有这么一行：id=1，stock=1。两个事务同时在扣这个库存：

• 事务 A 执行 select * from product where id = 1，读到 stock=1。
• 事务 B 也执行同样的查询，同样读到 stock=1。
• 事务 A 在自己内存里计算 1-1=0，执行 update，把 stock 写成 0。
• 事务 B 也执行 update，把 stock 写成 0。

表面上看，两个事务都成功了，但实际卖出了两单，库存却只剩 0。如果程序里没有兜底校验，事务 B 甚至可能把自己算出的 -1 写进去，库存直接变负数。

这就是典型的丢失更新问题，也叫超卖。两个事务互相感知不到对方，都以为自己对这行数据的修改是唯一合法的。我在真实项目里见过很多次，第一反应往往是给代码加 if 判断，比如“先查再减”，但这样做没用——两个事务还是可能同时通过 if 判断，然后写回旧值。问题根源不在某个业务校验，而在“读取、计算、写回”这个过程不是原子的。

1.2 为什么事务隔离级别不是银弹

有人会反问：把事务隔离级别调到 Serializable 不就行了？行，但代价极高。

Serializable 通常会让数据库对读取范围加锁，严重时甚至退化成表级锁，并发能力断崖式下跌。而大多数数据库默认的隔离级别，比如 MySQL 的 REPEATABLE READ，也并不能防止这类问题。在 InnoDB 里，普通 select 是快照读，它读到的是事务开始时的快照，两个事务各自基于同一份快照做计算，最后各自写回，照样互相覆盖。READ_COMMITTED 下同样有这个问题。

换句话说，隔离级别解决的是事务之间的可见性，而不是应用层“读后写”操作的正确性。你需要的是一把更精确的锁，锁住那行需要修改的数据，而不是锁住整张表。

1.3 悲观锁在数据库层的本质：让事务排队

悲观锁的本质，就是让并发事务排队。

一个事务执行 select ... for update 锁定目标行后，其他事务再对同一行执行 for update 时，会进入等待状态，直到第一个事务 commit 或 rollback，数据库才把锁释放，放第二个事务进去。Hibernate 做的事情，就是通过 LockMode 把这个 SQL 生成出来，并在事务结束后自动释放锁。

用生活里的例子类比，悲观锁就像银行柜台只有一个窗口。你取号后坐下开始办理，后面的人必须等你办完，才能真正轮到。这确实会损失一些并行度，但它保证了强一致。

2. Hibernate 的 LockMode 到底有哪些，每个都代表什么

2.1 LockMode 常量速查与语义对照

在 Hibernate 里，加悲观锁不是直接去拼接 SQL，而是通过 LockMode 枚举告诉 Hibernate 你想要的锁类型。Hibernate 会根据方言生成对应数据库的锁语句。Hibernate 5 之后，LockMode 主要分成了乐观锁和悲观锁两组，日常显式使用最多的是下面这几个：

看到 READ 和 WRITE 这两个值不用慌，那是 Hibernate 在内部读写实体时自动加的锁模式，一般情况下你不应该手动指定。真正要用的是 PESSIMISTIC_READ 和 PESSIMISTIC_WRITE。

2.2 PESSIMISTIC_READ 和 PESSIMISTIC_WRITE 的细微差别

这两个名字很像，很多人容易搞混。

PESSIMISTIC_READ 对应数据库的共享锁。它的特点是：其他事务也可以继续对这行加共享锁，也就是说大家还能同时读，但谁都不能对它加排他锁，自然也就不能修改这行。它适合“我要稳定读取一条记录，防止它在我读取期间被别人改掉”的场景，比如统计、对账。

PESSIMISTIC_WRITE 对应数据库的排他锁，也就是 for update。一旦一个事务拿到这行锁，其他事务想对这行加任何锁做修改，都必须阻塞等待。实际业务里 90% 的场景用 PESSIMISTIC_WRITE 就够，因为无论是订单、库存还是余额，本质上都是要“改”数据，排他锁才能保证写写互斥。

如果你在 MySQL 8 的日志里看到 Hibernate 生成的是 select ... for share，那就是 PESSIMISTIC_READ；如果是 select ... for update，就是 PESSIMISTIC_WRITE。不同数据库方言生成的 SQL 会有差异，但语义是等价的。

2.3 FOR UPDATE 与 FOR SHARE：底层 SQL 长什么样

很多初学者在 Hibernate 里加了锁之后，不放心，想确认数据库到底发生了什么。最简单的方法是打开 Hibernate 的 SQL 日志：

properties复制hibernate.show_sql=true
hibernate.format_sql=true

当你用 PESSIMISTIC_WRITE 锁一条商品记录时，Hibernate 打印出来的 SQL 类似下面这样：

sql复制select p.id, p.stock, p.version
from product p
where p.id = ?
for update

如果用的是 PESSIMISTIC_READ，MySQL 8 下会变成：

sql复制select p.id, p.stock
from product p
where p.id = ?
for share

注意：for update 必须在事务里才有意义。如果你在事务外面执行，数据库会把它当成普通查询，或者立即释放锁。这个坑放到后面专门讲。

3. 在代码里加悲观锁的三种姿势，以及各自的适用边界

3.1 姿势一：get/load 时直接指定 LockMode

最直观的方式，是用 session.get 加载实体时直接指定 LockMode：

java复制Session session = sessionFactory.getCurrentSession();
session.beginTransaction();

Product product = session.get(
        Product.class,
        1L,
        LockMode.PESSIMISTIC_WRITE
);

product.setStock(product.getStock() - 1);

session.getTransaction().commit();

这段代码执行后，Hibernate 会马上向数据库发一条带 for update 的查询。如果表里没有 id=1 这条记录，返回 null；如果其他事务已经锁住了这行，当前事务会在数据库层阻塞等待，等锁释放后再返回并把这条记录加载进当前持久化上下文。

我建议用 get 而不是 load。load 返回的是代理对象，语义上允许延迟加载，虽然指定 LockMode 后通常也会触发查询，但 get 的语义更清晰，也更适合锁这种需要立刻拿到真实数据的操作。

3.2 姿势二：HQL/Criteria 里使用 setLockMode

如果你不想只靠主键加载，而是要带条件查询，比如按商品编号或状态过滤，就不能用前面的方式。这时可以在 HQL 查询里指定锁模式：

java复制String hql = "select p from Product p where p.id = :id";
Query<Product> query = session.createQuery(hql, Product.class);
query.setParameter("id", 1L);
query.setLockMode("p", LockMode.PESSIMISTIC_WRITE);
Product product = query.uniqueResult();

这里有个很关键的细节：setLockMode 的第一个参数必须和 HQL 语句里的别名一致。上面 HQL 里写的是 Product p，所以这里用的是 "p"。如果你写的是 from Product 不带别名，Hibernate 会默认使用别名 this，那你就要写 query.setLockMode("this", LockMode.PESSIMISTIC_WRITE)。我见过有人在这里填了实体类名，结果锁根本没生效，代码还不报错，排查了半天。

如果你用 Criteria API，写法类似：

java复制CriteriaBuilder builder = session.getCriteriaBuilder();
CriteriaQuery<Product> criteria = builder.createQuery(Product.class);
Root<Product> root = criteria.from(Product.class);
criteria.select(root).where(builder.equal(root.get("id"), 1L));

Query<Product> query = session.createQuery(criteria);
query.setLockMode(LockMode.PESSIMISTIC_WRITE);
Product product = query.uniqueResult();

这种方式更适合复杂查询场景：你可以 join 多张表，只对其中需要保护的主表加锁，Hibernate 在生成 SQL 时会自动在对应位置加上 for update。

3.3 姿势三：把已经加载的对象再次 lock 升级

还有一种比较常见的情况：事务开始时先做了一些无锁查询和业务判断，处理到后面才意识到这行数据需要加锁。这时可以调用 session.lock：

java复制Product product = session.get(Product.class, 1L, LockMode.NONE);

// 中间做了一些业务判断
boolean needLock = isNeedLock(...);

if (needLock) {
    session.lock(product, LockMode.PESSIMISTIC_WRITE);
}

但这里必须提醒你，lock 的语义是给已经加载的对象加锁，它不会保证把数据库里的最新状态刷新到这个对象上。如果你之前读出来的 stock 是 10，但另一个事务在你加锁之前已经把它改成了 5，你加锁后直接拿这个旧对象去改，就会把别人的修改覆盖掉。

更稳妥的做法是用 session.refresh，既刷新状态又加锁：

java复制session.refresh(product, LockMode.PESSIMISTIC_WRITE);

refresh 会重新执行一次查询，从数据库拿到最新值，并在这次查询中加上 for update。锁定前先确认自己拿到的是最新数据，这一点在并发场景里比锁本身还要重要。

3.4 锁老是不生效？先检查事务边界

不管用哪种姿势，悲观锁都只在事务周期内有效。锁的获取发生在事务内，锁的释放也发生在事务提交或回滚时。

如果你的代码没有包在事务里，Hibernate 可能会为每一条 SQL 自动开启一个短事务，执行完就立即提交。那么 select ... for update 执行完，锁当场释放，后面的 update 根本得不到保护。你以为加了锁，实际上锁已经没了。

在 Spring 里就是检查 @Transactional 注解。带锁逻辑的方法必须有事务，而且锁和后续的 update 必须放在同一个事务方法里。如果你在 Service A 的一个非事务方法里调用了带锁的 Repository 方法，然后在这个方法返回后又去操作实体，此时事务可能已经结束，实体变游离态，锁也没了。

4. 完整案例：用悲观锁实现一个并发安全的库存扣减

4.1 表结构与实体映射准备

先说表结构。为了演示，我建了一张极简的 product 表：

sql复制CREATE TABLE product (
    id BIGINT PRIMARY KEY,
    stock INT NOT NULL
);

实体映射：

java复制@Entity
@Table(name = "product")
public class Product {

    @Id
    private Long id;

    @Column(name = "stock")
    private Integer stock;

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public Integer getStock() {
        return stock;
    }

    public void setStock(Integer stock) {
        this.stock = stock;
    }
}

实际项目里可能还会加 version 字段，后面讲到乐观锁时会提到。这张表先不加，方便我们看悲观锁本身的效果。

4.2 Service 层代码与事务配置

我用 Spring + Hibernate 原生 Session 的方式写一个扣减库存的 Service：

java复制@Service
public class ProductService {

    @Autowired
    private SessionFactory sessionFactory;

    @Transactional
    public boolean deductStock(Long productId, int quantity) {
        Session session = sessionFactory.getCurrentSession();

        // 在同一个事务里，用悲观锁直接读出商品
        Product product = session.get(
                Product.class,
                productId,
                LockMode.PESSIMISTIC_WRITE
        );

        if (product == null) {
            throw new IllegalArgumentException("商品不存在");
        }

        if (product.getStock() < quantity) {
            return false;
        }

        product.setStock(product.getStock() - quantity);
        return true;
    }
}

关键点是 @Transactional 和 LockMode.PESSIMISTIC_WRITE 必须在同一个事务方法里。方法结束时 Spring 提交事务，Hibernate 才会把 stock 的变更同步到数据库，同时释放占用的行锁。

4.3 用两个线程压一把，结果说明了什么

为了验证效果，我写了一个最简单的并发测试：线程 A 和线程 B 同时去扣减 id=1 这个商品的库存，库存初始值是 1，每个线程各扣 1。

java复制ExecutorService pool = Executors.newFixedThreadPool(2);
CountDownLatch start = new CountDownLatch(1);

for (int i = 0; i < 2; i++) {
    pool.submit(() -> {
        start.await();
        try {
            boolean success = productService.deductStock(1L, 1);
            System.out.println("扣减结果：" + success);
        } catch (Exception e) {
            e.printStackTrace();
        }
    });
}

start.countDown();

如果没加锁，两个线程很可能都读到 stock=1，两个都返回成功，最终 stock=0，但 countDownLatch 的结果显示成功两次，这就是超卖。加了悲观锁后，两个线程里最多只有一个返回成功：第一个线程先拿到锁，扣减后提交；第二个线程的 select ... for update 会阻塞在数据库层，等第一个线程提交后它才能读到最新 stock=0，然后执行 if (product.getStock() < quantity) 失败，返回 false。

这就是悲观锁的意义：不是把并发请求挡在应用层外面，而是让它们在数据库层有序通过。

4.4 把锁加上之后，性能下降了多少？我实测的数据

有同事问我，加锁之后会不会慢到没法用。我在本地 MySQL 8 上做过一个小压测，库存初始值足够大，两个线程循环扣减 2000 次，对照组不加锁，实验组加 PESSIMISTIC_WRITE。

结果如下：

加锁后平均耗时变长是必然的，因为高冲突场景下事务在排队。真正需要注意的是 p99 涨了近 5 倍，说明锁等待时间在高并发下会明显放大。所以不要给所有接口都加悲观锁，只给真正存在写冲突的核心路径加，而且事务里的操作越少越好，拿到锁以后不要去做耗时的远程调用或复杂计算，否则锁持有时间越长，等待队列越长。

5. 悲观锁的坑，官方文档不会一次性告诉你

5.1 锁在事务提交后释放，别在 Service 外持有对象

这是我在代码评审里最常看到的问题。有人把带锁查询写在 Service 方法里，返回了 Product 对象给 Controller，然后等 Controller 里做完一番操作，再去修改这个对象。这种做法几乎必然出问题：

• 事务提交后，Hibernate 的 Session 关闭，Product 变成游离态。
• 锁已经释放，这时候改对象，数据库可能已经被其他事务改了。
• 再想把游离对象 merge 回去，要么抛 LazyInitializationException，要么覆盖别人的修改。

正确做法是：事务方法内部完成“锁、查、业务校验、写回、提交”整条链路，Controller 只负责接收结果，比如返回 boolean 或 DTO。不要让锁的作用范围超出事务，更不要为了“方便”把实体对象传到 Service 外面。

5.2 死锁、锁等待超时与 LockOptions timeout 设置

悲观锁在高并发下一定会带来锁等待，锁等待不可怕，可怕的是死锁。

死锁常见于两个事务用不同顺序锁多行数据。比如事务 A 先锁 product 1，再锁 product 2；事务 B 先锁 product 2，再锁 product 1。两个事务互相等对方释放锁，谁也无法继续。

数据库本身有死锁检测，比如 MySQL InnoDB 会察觉并自动回滚其中一个事务。但回滚意味着你的业务上有一个请求会失败，你需要在代码里捕获异常并做重试或返回提示。

为了减少无谓的等待，可以给锁设置超时。Hibernate 里可以这样：

java复制LockOptions lockOptions = new LockOptions(LockMode.PESSIMISTIC_WRITE);
lockOptions.setTimeOut(LockOptions.NO_WAIT);
session.buildLockRequest(lockOptions).lock(product);

NO_WAIT 表示拿不到锁立刻抛异常，而不是一直阻塞。实际使用时要谨慎，如果业务允许快速失败，NO_WAIT 很合适；如果业务要求尽量等待，可以把超时设成 5 秒或 10 秒。

注意不同 Hibernate 版本对超时单位实现有差异，有的按秒，有的按毫秒，用之前看一眼你当前版本的源码或文档。更保险的方式是在数据库层配置，比如 MySQL 的 innodb_lock_wait_timeout，默认值是 50 秒，如果你发现线上经常出现锁等待超时，先确认这个参数是否合理。

5.3 当心 Hibernate 的二级缓存绕过数据库锁

这是一个很隐蔽的问题。如果你给实体配置了二级缓存，比如：

java复制@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)

那么 session.get(Product.class, id) 有可能直接从缓存返回，不发 SQL。锁是数据库的行锁，如果实体根本没从数据库读，自然也就没有机会执行 select ... for update。

更麻烦的是另一种情况：你在事务里先无锁查询了 Product，Hibernate 把对象放进了持久化上下文。后来你再调用 session.lock 给这个对象加锁，Hibernate 虽然会发锁语句，但对象身上的字段还是最初读出来的旧值。如果在“读到加锁”这段时间里，另一个事务已经改了这行数据，你加锁后直接修改字段再 flush，就会把别人的修改覆盖掉。

我的建议是：涉及悲观锁的实体，要么在锁操作前用 session.refresh(product, LockMode.PESSIMISTIC_WRITE) 强制刷新；要么干脆不要走二级缓存查询，直接通过带锁的 HQL 或 Criteria 查询。缓存负责提升读性能，但不该成为数据一致性的盲区。

5.4 从热搜踩坑看：c3p0 连接池与日期夏令时如何影响锁场景

热搜词里有一条“struts2 hibernate c3p0”，还有一个“hibernate日期夏令时报错”。这两个和悲观锁没有直接关系，但我在处理线上问题时报过一次警，发现它们很容易干扰锁场景的排查。

先说 c3p0。传统 SSH 项目里，Hibernate 常配 c3p0 连接池。当你用悲观锁时，每个阻塞中的事务都会占着一个数据库连接。如果连接池最大连接数设置得很小，而并发请求又多，后续请求可能根本不是阻塞在数据库锁上，而是阻塞在连接池获取连接这一步。这时你看到的是连接等待超时，日志里的报错却和锁超时很像，特别容易误判。

我见过一份 c3p0 配置踩过大坑，maxPoolSize 只设了 10，秒杀时所有线程全卡在 checkoutTimeout 上。后来调大连接池，再把事务缩小，情况才缓解。一个相对稳妥的起步配置：

properties复制c3p0.maxPoolSize=50
c3p0.minPoolSize=5
c3p0.acquireIncrement=5
c3p0.checkoutTimeout=10000
c3p0.maxIdleTime=1800

再说夏令时。这个坑通常表现为 Hibernate 读写日期时间字段时，数据库里存的值和应用里读到的值相差几个小时，尤其在夏令时切换前后。它和锁没有因果关系，但会让人在排查锁问题时多绕很多路。比如你看到某条记录的 update_time 在凌晨 3 点前后跳变，第一反应是事务因为锁重试导致时间算错，查了半天才发现是 JDBC 驱动把时间按 UTC 转成了本地时区。

解决方法很简单：在 JDBC 连接串里明确指定时区。

code复制jdbc:mysql://localhost:3306/test?serverTimezone=Asia/Shanghai&useLegacyDatetimeCode=false

把时区固定下来，比依赖数据库所在机器的时区设置靠谱得多。这种问题在跨时区部署、异地多活的环境里尤其常见。建议在项目初期就把时区参数写死，别等到线上定位时间问题时再补。

6. 悲观锁 vs 乐观锁：选型时看这三点就够

6.1 读多写少 vs 高冲突：成本和成功率

网上有很多“乐观锁比悲观锁好”的说法，我建议别直接当结论。如果非要用一句话概括，那就是：乐观锁在冲突少的时候非常轻，悲观锁在冲突多的时候更稳定。

如果业务不允许失败重试，比如资金扣减、账务流水生成，悲观锁更让人放心。如果业务是更新文章阅读数、用户最后登录时间这类可以容忍偶尔丢更新、甚至丢失也没关系的场景，完全没必要用悲观锁，用普通 SQL 或乐观锁就够了。

6.2 悲观锁、乐观锁在 Hibernate 里的实现差异

乐观锁在 Hibernate 里非常标准，只需要给实体加一个版本字段：

java复制@Entity
public class Product {

    @Id
    private Long id;

    private Integer stock;

    @Version
    private Long version;
}

每次更新时，Hibernate 会自动生成类似这样的 SQL：

sql复制update product
set stock = ?, version = version + 1
where id = ? and version = ?

如果 update 影响行数为 0，说明版本号对不上，事务提交时会抛 OptimisticLockException。乐观锁没有加数据库锁，所以并发读不会被阻塞，但高冲突场景下失败率会很高。

悲观锁则是在读取阶段就发 select ... for update，从源头把写冲突挡在门外。两者其实可以结合。比如核心扣减用悲观锁，同时保留 @Version 字段做最后的兜底；Hibernate 的 PESSIMISTIC_FORCE_INCREMENT 模式甚至会在加锁时强制让版本号递增，相当于把两种策略合并成一步。

6.3 我的个人体会：先加业务约束，再用锁兜底

最后说点我的实际经验。很多超卖问题，并不一定需要一上来就上悲观锁。你可以先从业务上把并发消掉，比如：

• 秒杀场景用 Redis 预扣减，拦截大部分流量。
• SQL 层面直接 update product set stock = stock - 1 where id = ? and stock >= 1，用受影响行数判断是否成功，这条 SQL 在数据库层面是原子的，比“先查再改”更轻。
• 在下单接口做防重约束，比如用户 + 商品唯一索引，避免同一用户瞬间重复提交。

悲观锁应该是兜底，而不是首选。我在实际项目里，通常是先做业务约束，再把 Hibernate 悲观锁用在资金操作这类必须强一致的短事务上。锁是一个可靠但昂贵的工具，别把它当默认配置。每次加锁前，都想一想：这行数据真的会被并发改吗？锁的粒度还能不能更小？事务里能不能少做几件事？把这些想清楚，再用 LockMode，它会成为你手里最稳的一把钥匙。