如何基于SQL查询实现块执行锁定 解决多实例下聊天室重复创建问题

问题根因 #

你使用的@Lock(LockModeType.PESSIMISTIC_READ)未生效的核心原因是：当目标聊天室不存在时，你的查询没有匹配到任何数据库行，自然无法对不存在的行加锁，两个并发事务都能得到「不存在」的查询结果，最终重复插入数据。同时悲观读锁是共享锁，就算查询到行也不会阻塞其他事务的读操作，本身就不适合这个写冲突场景。

可选解决方案 #

方案1：新增对话方集合唯一索引（最推荐，性能最优） #

该方案实现简单、可靠性最高，不需要额外加锁逻辑：

• 给chat_rooms表新增participants_unique_key字符串字段，为该字段添加唯一索引
• 每次创建聊天室前，先将本次请求的所有对话方ID做升序排序，拼接为固定格式字符串（比如对话方ID为2和1，排序后拼接为1,2），作为participants_unique_key的取值
• 插入chat_rooms记录时携带该字段，一旦出现重复的对话方集合，数据库会直接抛出唯一键冲突异常
• 业务代码捕获唯一键冲突异常后，直接执行已有聊天室查询逻辑返回即可

JPA实现提示：用@Column(unique = true)标注该字段，插入冲突时捕获DataIntegrityViolationException即可。

方案2：基于现有表行锁实现互斥（无需修改表结构） #

如果不想调整表结构，可以通过锁定关联对话方行实现并发控制：

1. 将整个聊天室创建逻辑包裹在同一个事务中
2. 事务开启后，先执行锁定对话方行的查询，SQL如下：

SELECT id FROM interlocutors WHERE id IN (?1, ?2) ORDER BY id FOR UPDATE;

必须加ORDER BY id保证每次锁定顺序一致，避免出现死锁
3. 成功拿到行锁之后，再执行你原有逻辑中的聊天室存在性查询
4. 确认聊天室不存在后，再执行创建逻辑，最后提交事务

原理：所有操作相同对话方集合的请求，都会先抢占这两个对话方行的写锁，同一时间只有一个事务能拿到锁，后续请求会阻塞在FOR UPDATE查询步骤。等前一个事务提交后，后续事务再执行存在性查询时，已经能拿到已创建的聊天室，不会重复插入。

JPA实现提示：给上述锁定对话方的查询方法添加@Lock(LockModeType.PESSIMISTIC_WRITE)注解即可。

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