数据库事务能否阻塞读取至其他事务完成？并发重复记录问题咨询

你的判断不正确，无需依赖代码级锁就能解决这个并发重复创建的问题，而且代码级锁在多实例部署场景下几乎无效。

为什么Serializable隔离级没生效？ #

Serializable是最高的事务隔离级别，理论上会让事务串行执行，但如果你的数据库开启了快照隔离（比如SQL Server的READ_COMMITTED_SNAPSHOT或ALLOW_SNAPSHOT_ISOLATION），默认的SELECT语句会采用快照读模式——它读取的是数据的版本快照，不会对数据加锁，也不会被其他事务的锁阻塞。这就导致两个并发事务都能读到“记录不存在”的结果，进而都执行插入操作，最终出现重复记录。

可靠的数据库层面解决方案 #

1. 给查询加排他性锁

修改查询语句，强制使用加锁读，让第一个事务的查询锁定目标范围，阻塞后续事务的相同查询，直到当前事务结束。以SQL Server为例，可以在EF中通过原生SQL实现：

var record = DbContext.SomeTable
    .FromSqlRaw("SELECT * FROM SomeTable WHERE id = {0} WITH (UPDLOCK, HOLDLOCK)", someId)
    .FirstOrDefault();

• UPDLOCK：对查询到的行加更新锁，如果未查到行，则会加范围锁，阻止其他事务插入符合条件的记录；
• HOLDLOCK：将锁持有到事务结束，避免锁提前释放导致并发问题。

2. 给id字段添加唯一约束

这是最稳妥的兜底方案，直接在数据库层面给id字段添加唯一键约束。即便两个事务都走到插入步骤，第二个事务的插入操作会因违反唯一约束被数据库直接拒绝，抛出异常。你只需在代码中捕获该异常，执行事务回滚或给用户返回重复提示即可。

代码级锁的局限 #

代码级锁（比如C#中的lock关键字）仅在单进程内有效，如果你的API部署在多个服务器（负载均衡场景），不同实例的锁相互独立，完全无法阻止跨实例的并发操作，扩展性极差，不推荐使用。

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