这个异常意味着_context同时被两个线程使用;同一个请求中的两个线程，或者由两个请求组成。

你的_context是否声明为静态?不应该如此。

或者您是否从代码中的其他地方在同一个请求中多次调用GetClients ?

你可能已经这样做了，但理想情况下，你会为你的DbContext使用依赖注入，这意味着你将在你的Startup.cs中使用AddDbContext()，你的控制器构造函数将看起来像这样:

private readonly MyDbContext _context; //not static

public MyController(MyDbContext context) {
    _context = context;
}

如果你的代码不是这样的，告诉我们，也许我们可以进一步帮助。

我不确定你是否使用IoC和依赖注入来解决你的DbContext可能被使用的地方。如果你使用了。net Core(或任何其他IoC- container)的原生IoC，并且你得到了这个错误，请确保将DbContext注册为Transient。做

services.AddDbContext<MyContext>(ServiceLifetime.Transient);

OR

services.AddTransient<MyContext>();

而不是

services.AddDbContext<MyContext>();

AddDbContext将上下文作为作用域添加，这在处理多线程时可能会带来麻烦。

当使用异步lambda表达式时，async / await操作也会导致这种行为。

将其添加为瞬态也有其缺点。你不能在多个使用上下文的类上修改某个实体，因为每个类都有自己的DbContext实例。

对此的简单解释是，DbContext实现不是线程安全的。你可以在这里阅读更多相关内容

我也遇到过同样的问题，但原因不是上面列出的那些。我创建了一个任务，在任务内部创建了一个作用域，并要求容器获取服务。这工作得很好，但后来我在任务中使用了第二个服务，我忘记了也要求它到新的范围。因此，第二个服务使用的DbContext已经被处理了。

Task task = Task.Run(() =>
    {
        using (var scope = serviceScopeFactory.CreateScope())
        {
            var otherOfferService = scope.ServiceProvider.GetService<IOfferService>();
            // everything was ok here. then I did: 
            productService.DoSomething(); // (from the main scope) and this failed because the db context associated to that service was already disposed.
            ...
        }
    }

我应该这样做的:

var otherProductService = scope.ServiceProvider.GetService<IProductService>();
otherProductService.DoSomething();

在某些情况下，当调用没有await关键字的异步方法时，会发生此错误，这可以通过在方法调用之前添加await来简单地解决。然而，答案可能与上述问题无关，但它可以帮助解决类似的错误。

我也收到了同样的信息。但这对我来说毫无意义。我的问题是我错误地使用了“NotMapped”属性。 在某些情况下，这可能只意味着Linq语法或模型类的错误。错误信息似乎具有误导性。这条消息的原始含义是你不能在同一个请求中对同一个dbcontext调用async多次。

[NotMapped]
public int PostId { get; set; }
public virtual Post Post { get; set; }

你可以点击这个链接了解详情， https://www.softwareblogs.com/Posts/Details/5/error-a-second-operation-started-on-this-context-before-a-previous-operation-completed

我也犯了同样的错误。发生这种情况是因为我调用了一个构造为公共异步void的方法…而不是公共async任务....

我认为这个答案仍然可以帮助一些人，节省很多时间。我通过将IQueryable更改为List(或数组，集合…)解决了类似的问题。

例如:

var list = _context.table1.Where(...);

to

var list = _context.table1.Where(...).ToList(); //or ToArray()...

我有一个后台服务，它为表中的每个条目执行一个操作。问题是，如果我在DbContext的同一个实例上遍历并修改一些数据，就会出现这个错误。

一个解决方案，正如在这个线程中提到的，是将DbContext的生存期更改为transient，方法是将它定义为

services.AddDbContext<DbContext>(ServiceLifetime.Transient);

但是因为我在多个不同的服务中做更改，并使用SaveChanges()方法一次性提交它们，这个解决方案在我的情况下不起作用。

因为我的代码是在服务中运行的，所以我做的事情就像

using (var scope = Services.CreateScope())
{
   var entities = scope.ServiceProvider.GetRequiredService<IReadService>().GetEntities();
   var writeService = scope.ServiceProvider.GetRequiredService<IWriteService>();
   foreach (Entity entity in entities)
   {
       writeService.DoSomething(entity);
   } 
}

能够像使用一个简单的请求一样使用服务。所以为了解决这个问题，我把一个作用域分成了两个，一个用于查询，另一个用于写操作，就像这样:

using (var readScope = Services.CreateScope())
using (var writeScope = Services.CreateScope())
{
   var entities = readScope.ServiceProvider.GetRequiredService<IReadService>().GetEntities();
   var writeService = writeScope.ServiceProvider.GetRequiredService<IWriteService>();
   foreach (Entity entity in entities)
   {
       writeService.DoSomething(entity);
   } 
}

像这样，实际上使用了两个不同的DbContext实例。

另一种可能的解决方案是确保在开始迭代之前读取操作已经终止。这在我的情况下不是很实际，因为可能有很多结果，都需要加载到内存的操作，我试图避免使用一个可查询的摆在首位。

我设法通过将IQueryable传入一个方法，然后使用IQueryable“列表”作为另一个查询的一部分，以相同的上下文来获得这个错误。

public void FirstMethod()
{
    // This is returning an IQueryable
    var stockItems = _dbContext.StockItems
        .Where(st => st.IsSomething);

    SecondMethod(stockItems);
}

public void SecondMethod(IEnumerable<Stock> stockItems)
{
    var grnTrans = _dbContext.InvoiceLines
        .Where(il => stockItems.Contains(il.StockItem))
        .ToList();
}

为了阻止这种情况发生，我使用了这里的方法，并在传递第二个方法之前将该列表物化，通过将对SecondMethod的调用更改为SecondMethod(stockItems.ToList()

首先，给alsami的答案点赞(至少)。这让我走上了正确的道路。

但是对于那些做IoC的人来说，这里有一些更深入的研究。

我的错误(和其他人一样)

发生了一个或多个错误。(第二次行动就此展开 上一个操作完成前的上下文。这通常是由于 不同的线程使用相同的DbContext实例。更多的 有关如何使用DbContext避免线程问题的信息，请参见 https://go.microsoft.com/fwlink/?linkid=2097913)。

我的代码设置。“只是基本的”……

public class MyCoolDbContext: DbContext{
    public DbSet <MySpecialObject> MySpecialObjects {        get;        set;    }
}

and

public interface IMySpecialObjectDomainData{}

和(注意MyCoolDbContext正在被注入)

public class MySpecialObjectEntityFrameworkDomainDataLayer: IMySpecialObjectDomainData{
    public MySpecialObjectEntityFrameworkDomainDataLayer(MyCoolDbContext context) {
        /* HERE IS WHERE TO SET THE BREAK POINT, HOW MANY TIMES IS THIS RUNNING??? */
        this.entityDbContext = context ?? throw new ArgumentNullException("MyCoolDbContext is null", (Exception)null);
    }
}

and

public interface IMySpecialObjectManager{}

and

public class MySpecialObjectManager: IMySpecialObjectManager
{
    public const string ErrorMessageIMySpecialObjectDomainDataIsNull = "IMySpecialObjectDomainData is null";
    private readonly IMySpecialObjectDomainData mySpecialObjectDomainData;

    public MySpecialObjectManager(IMySpecialObjectDomainData mySpecialObjectDomainData) {
        this.mySpecialObjectDomainData = mySpecialObjectDomainData ?? throw new ArgumentNullException(ErrorMessageIMySpecialObjectDomainDataIsNull, (Exception)null);
    }
}

最后，我的多线程类，从控制台应用程序(命令行接口应用程序)调用

    public interface IMySpecialObjectThatSpawnsThreads{}

and

public class MySpecialObjectThatSpawnsThreads: IMySpecialObjectThatSpawnsThreads
{
    public const string ErrorMessageIMySpecialObjectManagerIsNull = "IMySpecialObjectManager is null";

    private readonly IMySpecialObjectManager mySpecialObjectManager;

    public MySpecialObjectThatSpawnsThreads(IMySpecialObjectManager mySpecialObjectManager) {
        this.mySpecialObjectManager = mySpecialObjectManager ?? throw new ArgumentNullException(ErrorMessageIMySpecialObjectManagerIsNull, (Exception)null);
    }
}

以及DI的积累。(同样，这是一个控制台应用程序(命令行接口)…它表现出与web应用程序略有不同的行为)

private static IServiceProvider BuildDi(IConfiguration configuration) {
    /* this is being called early inside my command line application ("console application") */

    string defaultConnectionStringValue = string.Empty; /* get this value from configuration */

    ////setup our DI
    IServiceCollection servColl = new ServiceCollection()
        ////.AddLogging(loggingBuilder => loggingBuilder.AddConsole())

        /* THE BELOW TWO ARE THE ONES THAT TRIPPED ME UP.  */
        .AddTransient<IMySpecialObjectDomainData, MySpecialObjectEntityFrameworkDomainDataLayer>()
    .AddTransient<IMySpecialObjectManager, MySpecialObjectManager>()

    /* so the "ServiceLifetime.Transient" below................is what you will find most commonly on the internet search results */
     # if (MY_ORACLE)
        .AddDbContext<ProvisioningDbContext>(options => options.UseOracle(defaultConnectionStringValue), ServiceLifetime.Transient);
     # endif

     # if (MY_SQL_SERVER)
        .AddDbContext<ProvisioningDbContext>(options => options.UseSqlServer(defaultConnectionStringValue), ServiceLifetime.Transient);
     # endif

    servColl.AddSingleton <IMySpecialObjectThatSpawnsThreads,        MySpecialObjectThatSpawnsThreads>();

    ServiceProvider servProv = servColl.BuildServiceProvider();

    return servProv;
}

让我吃惊的是“transient for”的变化

        .AddTransient<IMySpecialObjectDomainData, MySpecialObjectEntityFrameworkDomainDataLayer>()
    .AddTransient<IMySpecialObjectManager, MySpecialObjectManager>()

注意，我认为因为IMySpecialObjectManager被注入到“MySpecialObjectThatSpawnsThreads”中，那些注入的对象需要是瞬态的才能完成链。

这一点是.......不只是(My)DbContext需要.Transient…而是DI图中更大的一块。

调试技巧:

这条线:

this.entityDbContext = context ?? throw new ArgumentNullException("MyCoolDbContext is null", (Exception)null);

将调试器断点放在这里。如果你的MySpecialObjectThatSpawnsThreads正在制作N个线程(例如10个线程)......这条线只被击中一次…那是你的问题。你的DbContext正在跨线程。

奖金:

我建议你阅读下面这篇文章(很老但很好)，关于网络应用程序和主机应用程序的区别

https://mehdi.me/ambient-dbcontext-in-ef6/

这里是文章的标题，以防链接发生变化。

使用实体框架6正确地管理dbcontext:深入 Mehdi El Gueddari导游

我用WorkFlowCore https://github.com/danielgerlag/workflow-core解决了这个问题

  <ItemGroup>
    <PackageReference Include="WorkflowCore" Version="3.1.5" />
  </ItemGroup>

示例代码如下..帮助未来的互联网搜索者

 namespace MyCompany.Proofs.WorkFlowCoreProof.BusinessLayer.Workflows.MySpecialObjectInterview.Workflows
    {
        using System;
        using MyCompany.Proofs.WorkFlowCoreProof.BusinessLayer.Workflows.MySpecialObjectInterview.Constants;
        using MyCompany.Proofs.WorkFlowCoreProof.BusinessLayer.Workflows.MySpecialObjectInterview.Glue;
        using MyCompany.Proofs.WorkFlowCoreProof.BusinessLayer.Workflows.WorkflowSteps;

        using WorkflowCore.Interface;
        using WorkflowCore.Models;

        public class MySpecialObjectInterviewDefaultWorkflow : IWorkflow<MySpecialObjectInterviewPassThroughData>
        {
            public const string WorkFlowId = "MySpecialObjectInterviewWorkflowId";

            public const int WorkFlowVersion = 1;

            public string Id => WorkFlowId;

            public int Version => WorkFlowVersion;

            public void Build(IWorkflowBuilder<MySpecialObjectInterviewPassThroughData> builder)
            {
                builder
                             .StartWith(context =>
                    {
                        Console.WriteLine("Starting workflow...");
                        return ExecutionResult.Next();
                    })

                        /* bunch of other Steps here that were using IMySpecialObjectManager.. here is where my DbContext was getting cross-threaded */


                    .Then(lastContext =>
                    {
                        Console.WriteLine();

                        bool wroteConcreteMsg = false;
                        if (null != lastContext && null != lastContext.Workflow && null != lastContext.Workflow.Data)
                        {
                            MySpecialObjectInterviewPassThroughData castItem = lastContext.Workflow.Data as MySpecialObjectInterviewPassThroughData;
                            if (null != castItem)
                            {
                                Console.WriteLine("MySpecialObjectInterviewDefaultWorkflow complete :)  {0}   -> {1}", castItem.PropertyOne, castItem.PropertyTwo);
                                wroteConcreteMsg = true;
                            }
                        }

                        if (!wroteConcreteMsg)
                        {
                            Console.WriteLine("MySpecialObjectInterviewDefaultWorkflow complete (.Data did not cast)");
                        }

                        return ExecutionResult.Next();
                    }))

                    .OnError(WorkflowCore.Models.WorkflowErrorHandling.Retry, TimeSpan.FromSeconds(60));

            }
        }
    }

and

ICollection<string> workFlowGeneratedIds = new List<string>();
                for (int i = 0; i < 10; i++)
                {
                    MySpecialObjectInterviewPassThroughData currentMySpecialObjectInterviewPassThroughData = new MySpecialObjectInterviewPassThroughData();
                    currentMySpecialObjectInterviewPassThroughData.MySpecialObjectInterviewPassThroughDataSurrogateKey = i;

                    ////  private readonly IWorkflowHost workflowHost;
                    string wfid = await this.workflowHost.StartWorkflow(MySpecialObjectInterviewDefaultWorkflow.WorkFlowId, MySpecialObjectInterviewDefaultWorkflow.WorkFlowVersion, currentMySpecialObjectInterviewPassThroughData);
                    workFlowGeneratedIds.Add(wfid);
                }

使用Startup.cs文件中的这行代码解决我的问题。 添加瞬态服务意味着每次请求该服务时，都会在您工作时创建一个新实例 与 依赖注入 服务。AddDbContext > <上下文(选项= > options.UseSqlServer (_configuration.GetConnectionString(“ContextConn”)), ServiceLifetime.Transient);

我知道这个问题在两年前就被问到过，但我刚刚遇到过这个问题，我使用的修复程序真的很有帮助。

如果你用同一个Context做两个查询，你可能需要删除AsNoTracking。如果你使用AsNoTracking，你会为每次读取创建一个新的数据读取器。两个数据读取器不能读取相同的数据。

我也有同样的问题，结果发现父母服务是一个单一的。所以context也自动变成了singelton。尽管在DI中被声明为每生命时间范围。

将具有不同生命周期的服务注入到另一个服务中

不要将作用域和瞬态服务注入到单例服务中。（ 这有效地将瞬态或作用域服务转换为 单例)。 永远不要将瞬态服务注入到作用域服务中(这会转换 将瞬态服务放入作用域。)

如果你的方法返回一些东西，你可以通过放 .工作结束的结果 . wait()如果它没有返回任何东西。

实体框架核心不支持在同一个DbContext实例上运行多个并行操作。这既包括异步查询的并行执行，也包括来自多个线程的任何显式并发使用。因此，总是立即等待异步调用，或者为并行执行的操作使用单独的DbContext实例。

你可以使用SemaphoreSlim来阻止下一个尝试执行EF调用的线程。

static SemaphoreSlim semSlim = new SemaphoreSlim(1, 1);

await semSlim.WaitAsync();
try
{
  // something like this here...
  // EmployeeService.GetList(); or...
  var result = await _ctx.Employees.ToListAsync();
}
finally
{
  semSlim.Release();
}

如果您创建了迁移(Add-Migration)，但忘记实际更新数据库(update - database)，也可能出现此错误。

有一些Async函数，但是你没有在它之前调用await。在调用该函数之前查找并添加await将对您有所帮助。

为这个错误添加另一个可能的解决方案，以防它帮助到某人。

在我的情况下，问题是在查询中使用nav属性，就像这样:

var selectedOrder = dbContext.Orders.Where(x => x.Id == id).Single();
var relatedOrders = dbContext.Orders.Where(x => x.User.Id == selectedOrder.User.Id).ToList();

问题是在查询中使用selectedOrder.User.Id。如果User nav属性还没有被加载，EF将在试图执行查询的过程中尝试延迟加载该属性，它认为这是试图开始第二个操作。解决方案是为selectedOrder.User创建一个单独的变量。Id，以确保在查询开始之前加载了查询所需的信息:

var selectedOrder = dbContext.Orders.Where(x => x.Id == id).Single();
var userId = selectedOrder.User.Id;
var relatedOrders = dbContext.Orders.Where(x => x.User.Id == userId).ToList();

将以下代码放入.csproject文件中并纠正所有错误

  <PropertyGroup>
     <WarningsAsErrors>CS4014</WarningsAsErrors>
  </PropertyGroup>

这段代码强制您使用await for异步方法