EF并行长任务引发CPU峰值与内存过高问题排查

架构老林

2026-7-30

ASP.NET Core 7 EF迁移后多线程长任务导致应用冻结问题

我正把C# ASP.NET Core 7项目从SqlClient原生SQL迁移到Entity Framework。项目里有个模拟场景，需要运行多个长任务，用大循环实现且用户能追踪进度，每个任务会在独立线程里多次写数据库。原SqlClient方案运行流畅，CPU和内存占用极低，但换成EF后，线程启动后应用直接停滞冻结。

我知道DbContext不是线程安全的，所以每个任务都创建独立DbContext，只在数据库插入时创建，用完就释放。即便如此，循环执行时电脑彻底冻结，Web应用无响应。

代码示例

控制器代码

public SmContext db { get; set; }

public SimulateRoundModel(SmContext db)
{
    this.db = db;
}

public async Task<IActionResult> OnPost()
{
    List<Match> matches = new CollectorClass(db).Collect();
    MyClass.Wrapper(matches);
    return Page();
}

核心Wrapper代码

public static void Wrapper(List<Match> matches)
{
    Parallel.For(0, matches.Count,
           index =>
           {
               matches[index].LongSim();
           });
}

Match类代码

private SmContext db { get; set; }

public Match(SmContext db)
{
    this.db = db;
}

public void LongSim()
{
    db.Dispose(); // 释放构造函数传入的主DbContext，不使用它

    using (SmContext db = new SmContext())
    {
        // 初始查询与插入操作
    }

    for (int i = 0; i < 100; i++)
    {
        Thread.Sleep(5000);

        // 模拟逻辑

        db = new SmContext();

        SomeInsert(); // 这些方法使用当前db执行插入
        SomeInsert();
        SomeInsert();

        db.Dispose();
    }
}

核心疑问

该场景涉及5-50个Match实例，原SqlClient方案下Parallel.For能高效处理甚至200个实例无异常。任务本身只有简单操作和少量查询，只是执行时长较长。希望在不大幅重构的前提下，实现进度保存到数据库的需求。

想问：这个方案有没有没察觉到的概念性问题，还是代码里有隐藏问题？

问题分析与修复建议

核心问题点

Parallel.For阻塞ASP.NET主线程
ASP.NET请求处理依赖线程池，Parallel.For会抢占大量线程池线程，且OnPost作为async方法却同步调用Wrapper，导致请求线程被长时间阻塞，Web应用无法处理其他请求，直接表现为冻结。原SqlClient方案因IO操作异步特性，线程占用更合理，而EF的同步操作加剧了线程池耗尽问题。
DbContext的错误处理
- 构造函数传入的DbContext属于请求生命周期实例，直接调用db.Dispose()会破坏整个请求的DbContext生命周期，引发其他依赖代码异常。
- 循环内创建DbContext后未用using包裹，若SomeInsert抛出异常，Dispose()可能无法执行，导致DbContext资源泄漏，积累后占用大量连接池连接和内存。
Thread.Sleep的线程阻塞
Thread.Sleep(5000)会让线程池线程被强制阻塞5秒，5-50个实例会导致大量线程被占用，线程池无足够资源处理其他请求，进一步加剧应用冻结。

修复方案

替换Parallel.For为异步并行处理
把Wrapper改为异步方法，用Task.WhenAll并行执行任务，避免阻塞线程池：

public static async Task Wrapper(List<Match> matches)
{
    var tasks = matches.Select(match => Task.Run(() => match.LongSimAsync()));
    await Task.WhenAll(tasks);
}

同时修改OnPost方法await调用：

public async Task<IActionResult> OnPost()
{
    List<Match> matches = new CollectorClass(db).Collect();
    await MyClass.Wrapper(matches);
    return Page();
}

修正DbContext的使用方式

不在Match类中接收注入的DbContext，需要时直接实例化或通过依赖注入获取范围实例（更推荐）。
所有DbContext使用都用using包裹，确保异常场景下也能正确释放：

public async Task LongSimAsync()
{
    using (SmContext db = new SmContext())
    {
        // 初始查询与插入操作
    }

    for (int i = 0; i < 100; i++)
    {
        await Task.Delay(5000); // 替换Thread.Sleep为非阻塞延迟

        // 模拟逻辑

        using (SmContext db = new SmContext())
        {
            SomeInsert(db); // 将DbContext作为参数传入方法，避免依赖实例字段
            SomeInsert(db);
            SomeInsert(db);
        }
    }
}

同步修改SomeInsert方法，接收DbContext参数：

private void SomeInsert(SmContext db)
{
    // 执行插入逻辑
}

替换Thread.Sleep为Task.Delay
Task.Delay是异步延迟，不会阻塞线程池线程，线程可被释放回池处理其他请求，大幅降低线程占用率。

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

EF并行长任务引发CPU峰值与内存过高问题排查

代码示例 #

控制器代码 #

核心Wrapper代码 #

Match类代码 #

核心疑问 #

问题分析与修复建议 #

核心问题点 #

修复方案 #