为何无法实现仅用于只读操作的线程安全DbContext？

DbContext从设计之初就不是为多线程场景打造的，哪怕是只读操作也没法做到线程安全，核心原因在于它内部很多组件的状态都是非线程安全的，并非只有变更跟踪器这一个点。

除变更跟踪器外，导致DbContext非线程安全的其他因素 #

• 查询缓存与状态共享：DbContext内部会缓存查询计划、实体元数据等信息，这些缓存结构大多没有做线程同步处理。当多个线程同时触发查询时，可能会同时修改缓存，导致缓存数据错乱，进而返回错误的查询结果。
• 实体实例复用：默认情况下，DbContext会通过一级缓存（内存中的实体实例）复用已加载的实体。如果多个线程同时访问同一个DbContext实例，可能会出现一个线程正在读取实体，另一个线程触发的查询刚好更新了这个实体的状态，导致读取到不一致的数据。
• 数据库连接管理：DbContext会管理数据库连接的生命周期，虽然只读操作不会修改连接状态，但多线程并发请求可能会导致连接池的混乱，或者在连接打开/关闭时出现竞争条件，引发异常。
• 内部状态维护：除了变更跟踪器，DbContext还维护着诸如实体类型配置、查询提供器的状态、事务上下文等内部数据结构。这些结构的访问和修改没有线程安全保障，并发操作很容易导致状态损坏。

为何“ReadOnlyDbContext”无法实现 #

哪怕专门做一个“ReadOnlyDbContext”，也绕不开上述问题：

1. 性能损耗问题：要让它线程安全，就需要给所有内部共享状态加锁，但多线程场景下的锁竞争会大幅降低并发效率，反而不如每个线程单独创建DbContext实例来得高效。
2. 设计定位冲突：DbContext的核心设计是工作单元模式，它的定位是短期存在的、单次请求/操作的上下文，而非长期驻留的共享实例。就算去掉变更跟踪器，剩下的缓存、连接管理等组件依然无法安全地在多线程下共享。
3. 查询优化的牺牲：EF Core的查询优化依赖于上下文的状态感知（比如一级缓存复用），如果强制做线程安全，就必须牺牲这些优化点，导致查询性能下降，失去了使用DbContext的意义。

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