EF Core如何处理并发冲突 EF Core并发控制方法

EF Core 默认采用乐观并发控制，通过时间戳（RowVersion）或普通字段作为并发令牌，在 UPDATE 的 WHERE 条件中校验，冲突时抛出 DbUpdateConcurrencyException，需捕获后读取数据库值、对比并重试。

EF Core 默认采用乐观并发控制（Optimistic Concurrency Control），不锁数据，而是在 SaveChanges 或 SaveChangesAsync 执行更新/删除时，检查关键字段是否被其他操作改过。一旦发现不一致，就抛出 DbUpdateConcurrencyException，由你决定怎么处理——不是自动覆盖，而是交还控制权。

用时间戳（RowVersion）做最稳妥的并发令牌

这是推荐做法，尤其在 SQL Server 中。数据库自动生成并维护 rowversion 字段，每次更新整行都会变，完全无需业务代码干预。

实体类中加 1771256774 特性，类型为 byte[]：

public class Product
{
  public int Id { get; set; }
  public string Name { get; set; }
  1771256774
  public byte[] RowVersion { get; set; }
}

EF Core 会自动把该字段加入 UPDATE 的 WHERE 条件，例如：
UPDATE Products SET Name = @p0 WHERE Id = @p1 AND RowVersion = @p2
若 WHERE 不匹配（说明别人已更新），影响行数为 0，触发异常

用普通字段做并发令牌（需手动维护）

适合 MySQL、PostgreSQL 等不支持 rowversion 的数据库，或业务上有意义的字段（如 LastModified、Version）。

用 Fluent API 标记字段为并发令牌：

modelBuilder.Entity()
.Property(p => p.Version)
.IsConcurrencyToken();

注意：你得在每次更新前主动递增或刷新这个值（比如 entity.Version++ 或 entity.LastModified = DateTime.UtcNow）
否则它不会变，起不到检测作用

捕获并处理 DbUpdateConcurrencyException

异常发生后，别直接报错，要读取当前数据库真实值，再决定合并策略。

遍历 ex.Entries 获取每个冲突实体
调用 entry.GetDatabaseValuesAsync() 拿到最新数据库快照
对比 OriginalValues（你加载时的值）、CurrentValues（你修改后的值）、DatabaseValues（别人刚写入的值）
常见策略有：客户端优先（强制覆盖）、服务端优先（丢弃本次修改）、手动合并（比如只保留用户改的 Name，保留数据库的 Status）
调用 entry.OriginalValues.SetValues(databaseValues) 同步原始值后，可重试 SaveChangesAsync

避免并发问题的补充建议

对高竞争字段（如库存、余额），考虑结合数据库原生操作（UPDATE ... SET Stock = Stock - 1 WHERE Stock >= 1）绕过 EF 的乐观锁逻辑
短事务 + 快速响应，减少“读-改-写”窗口期
前端提交前可加版本号校验（比如把 RowVersion 作为隐藏字段传回），提前提示用户数据已变更
悲观锁（如 SELECT ... FOR UPDATE）在 EF Core 中需手动写原生 SQL 或使用事务隔离级别，不推荐作为默认方案

基本上就这些。核心就三点：选对令牌字段、理解 WHERE 条件怎么生成、异常来了别慌——读、比、定、重试。

# mysql # 前端 # sql # String # for # select # timestamp # int # class # public # Property # 并发 # postgresql # 数据库 # 令牌 # 重试 # 抛出 # 这是 # 是在 # 来了 # 遍历 # 上有 # 不支持 # 三点

返回目录在线咨询

上一篇：拉勾网源码,新媒体运营是做什么的？
下一篇：日本网站代理服务器是否安全？如何确保数据隐私？

您的项目需求