企业官网建设流程全解析

EF Core 并行查询需确保线程安全

由于 EF Core 中的 `DbContext` 类并非线程安全的，所以每当要并发执行多个查询时，必须采取措施确保线程安全。EF Core 是微软的旗舰 ORM（对象关系映射器），这一软件层让 .NET 开发者能够与关系型数据库进行交互。`DbContext` 类是 EF Core 框架中管理数据库操作的核心组件，但它不具备线程安全性。若在多个线程间共享 `DbContext` 实例，往往会遭遇数据损坏问题和 `InvalidOperationException` 异常。在本文中，将学习如何通过处理线程安全问题，在 EF Core 中并行执行查询，从而避免并发错误。若要运行本文提供的代码示例，系统中需安装 Visual Studio 2026，可从指定位置下载。

1. EF Core 查询并行执行的问题

在如今的数据驱动型应用程序开发中，常常需要从多个不相关的数据集中获取数据。在使用并发的应用程序里，线程安全对于保证正确执行、避免数据损坏和竞态条件，以及确保数据一致性至关重要。下面通过一个示例来理解。假设要填充一个仪表盘，展示所有最近处理的订单、指标、日志和跟踪信息，以及应用程序的性能元数据。编写的代码中，有四个读取操作由四个不同的 `Task` 实例执行，目标是让数据库往返操作并行运行，可通过 `Task.WhenAll` 来实现，它会启动这四个任务，等待每个任务完成，然后将数据封装在一个新的 `Dashboard` 实例中返回。若按顺序执行这些查询，用户就得依次等待每个查询执行完毕，总等待时间等于四个查询时间之和；但通过并行运行这些查询，能大幅减少等待时间，用户只需等待四个查询中最慢的那个完成即可。然而，上述方法存在风险。若在同一个 `DbContext` 实例上运行多个操作，会看到 `InvalidOperationException` 异常。像 SQL Server、PostgreSQL 和 Oracle Database 这类数据库，在连接层面遵循请求 - 响应通信模型，即单个连接一次只能处理一个命令，所以不能使用同一个连接并发运行多个查询。若使用同一个连接等待多个操作，EF Core 会检测到对非线程安全上下文的重叠使用，并抛出 `InvalidOperationException` 异常。要并行运行查询，必须为每个任务提供独立的连接或上下文。

2. `DbContext` 非线程安全的原因及解决办法

EF Core 中的 `DbContext` 类旨在管理单个工作单元，EF Core 不支持在同一个 `DbContext` 实例上运行多个操作。这种设计方式在跨多个线程使用同一个 `DbContext` 实例时会带来固有挑战。若 `DbContext` 具备线程安全性，就需要大量的锁机制，这会降低数据访问性能。`DbContext` 的有状态设计使其不适合涉及同时加载、修改或跟踪不同数据集的并发访问模式，因为它需要维护数据库状态的内部表示。变更跟踪器是 EF Core 中 `DbContext` 最重要的组件之一，它会监控所有加载到内存中的实体，并检测加载后对它们所做的任何更改，记录实体的原始值、当前值和更改后的值，这样在调用 `DbContext` 实例的 `SaveChanges()` 方法时，EF Core 运行时就能了解这些实体的当前状态。在使用 `DbContext` 时实现线程安全，代码必须确保每个并发操作都有自己的短期实例副本。可以使用 `lock` 关键字将共享的 `DbContext` 实例包装在一个线程安全块中，这样所有对数据库的调用就会一次只由一个线程执行，但这种方法会显著降低数据访问性能。更好的方法是使用 `IDbContextFactory`，它能按需创建全新的 `DbContext` 实例。调用其 `CreateDbContext()` 方法成本较低，且每次都会生成一个全新的、独立的上下文。

3. EF Core 查询并行执行的解决方案

现在来看看如何使用 `IDbContextFactory`。代码展示了一个名为 `ProductService` 的类，它使用工厂为每个工作范围创建 `DbContext` 实例。`ProductService` 有两个方法：`GetByIdAsync` 和 `UpdateStockQuantityAsync`，在这两个方法中，都会在本地创建一个 `DbContext` 类的实例。假设现在有两个线程 `T1` 和 `T2` 并发执行这些方法，由于这些方法是独立执行的，它们会有各自的上下文、连接和变更跟踪信息，且不存在可变状态，所以无需在这些方法中实现线程同步。代码展示了如何在两个单独的任务中分别执行读取操作和更新操作，`Task.WhenAll` 方法会并行运行这两个任务，并等待它们全部完成。这种方法具有线程安全性且不会产生并发错误的原因在于，这两个方法内部都会创建自己的 `DbContext` 实例，所以读取操作和更新操作使用的是独立的 `DbContext` 实例。

4. 使用 `DbContext` 池降低分配成本

虽然创建 `DbContext` 实例的成本不算太高，但对于需要高可扩展性和高性能的应用程序，还是应该考虑使用池化上下文。代码片段展示了如何注册一个池化上下文。调用 `AddDbContext()` 会将 `DbContext` 实例注册为每个 HTTP 请求作用域内的实例，每个请求会在不同的线程上运行，且都有自己的上下文。不过要注意，`DbContext` 的默认作用域注册并不总是能满足需求。在使用后台服务、在特定请求内执行某些工作，或者在多个上下文中运行某些业务逻辑操作时，就需要一个工厂来创建 `DbContext` 实例。

要点总结

若在应用程序的数据访问层使用 EF Core，并行运行查询时必须实施线程安全措施。不能使用同一个 `DbContext` 实例在 EF Core 中并行执行多个查询。`IDbContextFactory` 能为每个线程创建一个 `DbContext` 实例，从而实现对这些实例的独立操作。虽然使用 `DbContext` 池会有少量的分配开销，但在需要高吞吐量的情况下，这就不是问题了。