ASP.NET Core .NET 5 后台并行处理队列任务的可行性及优化

• 无上限的资源耗尽风险
  你现在的逻辑是每从队列取到一个任务就立刻启动独立线程执行，没有任何并发数限制。由于工作簿转换是CPU密集型任务，单任务执行时会占满一个CPU核的时间片，同时加载大型工作簿会占用几百MB到数GB的内存。如果队列积压了几十上百个任务，会瞬间开出远超服务器CPU核心数的线程，最终因为线程上下文切换开销飙升、内存占满，直接导致进程OOM崩溃、Web接口响应超时，甚至整台服务器无响应。
• 优雅停机机制完全失效
  你现在启动的所有后台任务都没有被await跟踪，也没有全局的任务引用列表。当应用收到停止信号（比如站点发布、服务器重启）时，队列消费循环会立刻退出，但已经启动正在运行的转换任务会被直接强制终止，导致正在处理的文件损坏、用户已上传的大文件浪费，而且因为没有任务跟踪，你根本没法在停机阶段等待这些未完成的任务收尾。
• API使用的固有缺陷
  Task.Factory.StartNew是早期的异步API封装，默认参数容易出现调度逻辑混乱的问题，搭配TaskCreationOptions.LongRunning时会直接为每个任务创建独立的非托管线程，进一步加剧线程资源的无意义消耗——当任务数远超CPU核心数时，独立线程带来的开销比复用线程池的线程高得多。

核心思路是在保证并行吞吐的前提下，给并发加硬限制、做任务全生命周期跟踪，兼顾资源稳定性和优雅停机能力，具体实现要点：

• 用SemaphoreSlim做并发数硬限制，CPU密集型任务的最大并发值设置为服务器CPU逻辑核心数（可留10%左右余量给Web请求处理），从根源上避免资源耗尽。
• 用线程安全的集合跟踪所有正在运行的任务，应用停机时，先停止从队列拉取新任务，再等待所有在跑的任务完成（可配置最长等待超时），保证执行不中断。
• 用Task.Run替换Task.Factory.StartNew，这是.NET框架推荐的CPU密集型任务启动方式，默认复用线程池，避免不必要的独立线程开销。
• 加全局异常兜底，尤其是工作簿转换这类常依赖非托管组件的场景，注册全局未处理异常捕获逻辑，避免单任务崩溃拖垮整个进程。

核心实现参考代码：

// 初始化时按CPU核心数设置最大并发数
private readonly SemaphoreSlim _concurrencyLimiter = new SemaphoreSlim(Environment.ProcessorCount);
// 线程安全集合跟踪所有运行中的任务
private readonly ConcurrentDictionary<Task, byte> _runningTasks = new ConcurrentDictionary<Task, byte>();

private async Task BackgroundProcessing(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        var workItem = await TaskQueue.DequeueAsync(stoppingToken);
        // 等待信号量获取许可，达到并发上限时自动排队
        await _concurrencyLimiter.WaitAsync(stoppingToken);
        
        var task = Task.Run(() =>
        {
            try
            {
                workItem(stoppingToken);
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "工作项执行失败");
            }
            finally
            {
                // 任务完成后释放信号量，允许下一个任务启动
                _concurrencyLimiter.Release();
            }
        }, stoppingToken);
        
        // 跟踪运行中的任务，任务完成后自动从列表移除
        _runningTasks.TryAdd(task, 0);
        _ = task.ContinueWith(t => _runningTasks.TryRemove(t, out _), TaskContinuationOptions.ExecuteSynchronously);
    }
    
    // 收到停止信号后，等待所有在跑任务完成
    await Task.WhenAll(_runningTasks.Keys);
}

落地补充注意事项 #

• 不要盲目调大并发数，CPU密集型任务的吞吐峰值刚好出现在并发数等于CPU核心数的时候，再往上加并发只会因为线程上下文切换降低整体处理速度。
• 配套加基础监控指标：队列积压长度、在跑任务数、单任务处理时长，当队列积压超过阈值时，及时扩容或者给前端提示任务排队状态。
• 如果后续任务量级持续增长，建议把后台转换逻辑从Web进程中拆分出去，用独立的Worker服务进程承载任务，Web进程只负责文件上传和任务状态查询，就算Worker进程出现异常，也不会影响核心Web服务的可用性。

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