Entity Framework 6.4.4 运行10-20小时突发大量EF物化错误求因及临时方案

• EF6 全局元数据缓存损坏：EF6 的实体映射、表列匹配规则等元数据是全局缓存在当前 AppDomain 中的，本身不是完全线程安全的。如果你的代码中存在运行时动态修改映射约定、动态构建 DbModel、或者使用了未做并发控制的第三方EF扩展组件，高并发场景下会出现元数据的映射关系错位，导致查询返回的列顺序和实体属性对应不上，就会出现把Byte类型值赋值给Guid、DateTime属性的报错，这和你描述的“运行很久后突然爆发、基础方法也报错”的特征完全吻合。
• DbContext 跨线程共享：EF6 的 DbContext 设计上是非线程安全的，很多团队为了省事会把 DbContext 注册为单例，或者在多线程任务中共享同一个 DbContext 实例，高负载下并行查询会导致内部结果物化器（Shaper）的状态错乱，返回的结果集和预期的实体映射不匹配。
• 运行时 Schema 变更：如果你的服务存在运行时动态切换数据库连接、或者后台有任务会修改表结构（增删列、调整列顺序），EF6 不会自动刷新已缓存的元数据，也会触发这类映射错误。

• 首先确认 DbContext 的生命周期配置，必须改为请求级/作用域级，每次查询新建实例，用完立即释放，绝对禁止单例使用或者跨线程共享。
• 紧急止血可以加一个错误检测逻辑：短时间内累计出现超过5次这类物化错误时，自动优雅重启服务进程，EF的元数据会在进程重启后重新生成，1分钟内即可恢复业务。
• 可以设置定时任务，每8小时（低于你当前故障触发的10小时阈值）主动优雅重启一次服务，规避长时间运行后元数据损坏的问题。
• 排查所有自定义EF约定、扩展代码，所有映射配置必须放在OnModelCreating方法中执行，禁止服务运行过程中动态修改映射规则。

该问题基本可以确定和高负载直接相关：低负载场景下即使存在非线程安全的代码，并发冲突的概率极低，只有累计请求量、并发量达到一定阈值后，才会触发元数据或者物化器的状态错乱。你可以通过压测复现：模拟生产2倍的并发量持续跑压测任务，能大幅缩短故障出现的时间，即可确认相关性。

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