【译】You probably should stop using a custom TaskScheduler

来自Sergey Tepliakov的 https://sergeyteplyakov.github.io/Blog/csharp/2024/06/14/Custom_Task_Scheduler.html

如果你不知道什么是TaskScheduler 或你的项目中没有它的自定义实现，你可能可以跳过这篇文章。但如果你不知道它是什么，但你的项目中确实有一两个，那么这篇文章绝对适合你。

让我们从基础开始。任务并行库（也称为TPL）引入于2010年的NET 4.0。当时它主要用于并行编程，而不是异步编程，因为异步编程在C#4和NET 4.0中不是一等公民。

例如，体现在TPL API中，Task.Factory.StartNew的入参为委托，返回void或T，而不是Task或Task<T>:

var task = Task.Factory.StartNew(() => 	 { 		Console.WriteLine("Starting work..."); 		Thread.Sleep(1000); 		Console.WriteLine("Done doing work."); 	}); 

Task.Factory.StartNew 有相当多的重载，其中一个需要 TaskScheduler .这是一种定义如何在运行时执行任务的策略。

默认情况下（如果未传递自定义 TaskScheduler 项，同时 TaskCreationOptions.LongRunning 未传递自定义项），则使用默认 TaskScheduler 。这是一个称为 ThreadPoolTaskScheduler 的内部类型，它使用 .NET 线程池来管理任务。（如果 传递TaskCreationOptions.LongRunning参数 给 Task.Factory.Startnew ，则使用专用线程来避免长时间使用线程池中的线程）。
与任何新技术一样，当 TPL 发布时，书呆子们很兴奋，并试图尽可能多地使用（和滥用）新技术。如果Microsoft给你一个可扩展的库，有些人认为这是一个好主意......你知道的。。。扩展它。
最常见的模式之一是并发限制，它使用固定数量的专用线程来确保您不会超额订阅 CPU：

public sealed class DedicatedThreadsTaskScheduler : TaskScheduler {     private readonly BlockingCollection<Task> _tasks = new BlockingCollection<Task>();     private readonly List<Thread> _threads;      public DedicatedThreadsTaskScheduler(int threadCount)     {         _threads = Enumerable.Range(0, threadCount).Select(i =>         {             var t = new Thread(() =>             {                 foreach (var task in _tasks.GetConsumingEnumerable())                 {                     TryExecuteTask(task);                 }             })             {                 IsBackground = true,             };              t.Start();             return t;          }).ToList();     }      protected override void QueueTask(Task task) => _tasks.Add(task);      public override int MaximumConcurrencyLevel => _threads.Count;      protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued) => false;      protected override IEnumerable<Task> GetScheduledTasks() => _tasks; } 

此外还有很多其他实现执行相同的操作： DedicatedThreadTaskScheduler 、、 DedicatedThreadsTaskScheduler ， LimitedConcurrencyLevelTaskScheduler 甚至 IOCompletionPortTaskScheduler 使用 IO 完成端口来限制并发性。

无论实现和幻想如何，它们都做同样的事情：它们最多允许同时执行给定数量的任务。下面是一个示例，说明我们如何使用它来强制最多同时运行 2 个任务：

var sw = Stopwatch.StartNew(); // Passing 2 as the threadCount to make sure we have at most 2 pending tasks. var scheduler = new DedicatedThreadsTaskScheduler(threadCount: 2); var tasks = new List<Task>(); for (int i = 0; i < 5; i++) {     int num = i;     var task = Task.Factory.StartNew(() =>     {         Console.WriteLine($"{sw.Elapsed.TotalSeconds}: Starting {num}...");         Thread.Sleep((num + 1) * 1000);         Console.WriteLine($"{sw.Elapsed.TotalSeconds}: Finishing {num}");     }, CancellationToken.None, TaskCreationOptions.None, scheduler);          tasks.Add(task); }  await Task.WhenAll(tasks); 

在本例中，我们在循环中创建任务，实际上它可能在某种请求中。下面是输出：

0.0154143: Starting 0... 0.0162219: Starting 1... 1.0262272: Finishing 0 1.0265169: Starting 2... 2.0224863: Finishing 1 2.0227441: Starting 3... 4.0417418: Finishing 2 4.041956: Starting 4... 6.0332304: Finishing 3 9.0453789: Finishing 4 

正如你所看到的，一旦任务 0 完成，我们会立即安排任务 1 等，所以实际上我们在这里限制了并发性。

但是让我们做一点点小小的改动：

static async Task FooBarAsync() {     await Task.Run(() => 42); }  ... var task = Task.Factory.StartNew(() => {     Console.WriteLine($"{sw.Elapsed.TotalSeconds}: Starting {num}...");     Thread.Sleep((num + 1) * 1000);     FooBarAsync().GetAwaiter().GetResult();     Console.WriteLine($"{sw.Elapsed.TotalSeconds}: Finishing {num}"); }, CancellationToken.None, TaskCreationOptions.None, scheduler); 

输出为：

0.0176502: Starting 1... 0.0180366: Starting 0... 

是的。死锁了！为什么？让我们更新一个示例以更好地查看问题：让我们跟踪当前 TaskScheduler 并将循环中创建的任务数减少到 1：

static void Trace(string message) =>      Console.WriteLine($"{message}, TS: {TaskScheduler.Current.GetType().Name}");  static async Task FooBarAsync() {     Trace("Starting FooBarAsync");     await Task.Run(() => 42);     Trace("Finishing FooBarAsync"); }  static async Task Main(string[] args) {     var sw = Stopwatch.StartNew();     var scheduler = new DedicatedThreadsTaskScheduler(threadCount: 2);     var tasks = new List<Task>();     for (int i = 0; i < 1; i++)     {         int num = i;         var task = Task.Factory.StartNew(() =>         {             Trace($"{sw.Elapsed.TotalSeconds}: Starting {num}...");             Thread.Sleep((num + 1) * 1000);             FooBarAsync().GetAwaiter().GetResult();             Trace($"{sw.Elapsed.TotalSeconds}: Finishing {num}...");         }, CancellationToken.None, TaskCreationOptions.None, scheduler);                  tasks.Add(task);     }  	Trace("Done scheduling tasks...");     await Task.WhenAll(tasks); } 

输出为：

0.018728: Starting 0..., TS: DedicatedThreadsTaskScheduler Starting FooBarAsync, TS: DedicatedThreadsTaskScheduler Finishing FooBarAsync, TS: DedicatedThreadsTaskScheduler 1.028004: Finishing 0..., TS: DedicatedThreadsTaskScheduler Done scheduling tasks..., TS: ThreadPoolTaskScheduler 

现在应该相对容易理解发生了什么以及为什么当我们尝试运行超过 2 个任务时会陷入死锁。请记住，异步方法中的每个步骤（关键字 await后的代码）本身就是一个任务，由任务调度程序逐个执行。默认情况下，任务调度程序是粘性的：如果TaskScheduler是在创建任务时提供的，那么所有后续的Task都将使用相同的TaskScheduler。这意味着TaskScheduler贯穿所有异步方法中的 awaits。

在我们的例子中，这意味着当完成 FooAsync时 ，我们 DedicatedThreadsTaskScheduler 被调用来运行它的后续的Task（译者注：即await Task.Run(() => 42);）。但是它已经忙于运行所有任务，因此它无法在 FooAsync 末尾运行一段微不足道的代码。而且由于 FooAsync 无法完成，我们无法立即完成Task。导致死锁。

我们能做些什么来解决这个问题？

解决方案

有几种方法可以避免此问题：

1. Use ConfigureAwait(false)

static async Task FooBarAsync() {     Trace("Starting FooBarAsync");     await Task.Run(() => 42);     Trace("Finishing FooBarAsync"); } 

我们在这里看到的问题与UI案例中的死锁非常相似，当任务被阻塞并且单个UI线程无法运行继续时。

我们可以通过确保每个异步方法都有 ConfigureAwait(false) 来避免这个问题。下面是具有以下 FooBarAsync 的实现时的输出。

static async Task FooBarAsync() {     Trace("Starting FooBarAsync");     await Task.Run(() => 42).ConfigureAwait(false);     Trace("Finishing FooBarAsync"); } 

0.0397394: Starting 0..., TS: DedicatedThreadsTaskScheduler Starting FooBarAsync, TS: DedicatedThreadsTaskScheduler **Finishing FooBarAsync, TS: ThreadPoolTaskScheduler** 1.0876967: Finishing 0..., TS: DedicatedThreadsTaskScheduler 

有人可能会说这是解决这个问题的正确方法，但我不同意。在我们的一个项目中，有一个实际案例，一个很难修复的库代码中存在阻塞异步方法。你可以通过使用分析器来确保你的代码遵循最佳实践，但期望每个人都遵循这些最佳实践是不切实际的。

（译者注：同样可以使用Fody来自动实现追加.ConfigureAwait(false);)

这里最大的问题是，这是一个不常见的情况。有许多后端系统在没有 ConfigureAwait(false) 的情况下工作得很好，因为团队没有任何带有同步上下文的 UI，而且任务调度程序的行为方式相同这一事实并不广为人知。

我只是觉得有更好的选择。

2. 以更明确的方式控制并发

我认为并发控制（又称速率限制）是应用程序非常重要的方面，重要的方面应该是明确的。

TaskScheduler 相当低级别的工具，我宁愿拥有更高级别的工具。如果工作是 CPU 密集型的，那么 PLINQ 或类似 ActionBlock TPL DataFlow 的东西可能是更好的选择。
 
如果工作主要是 IO 绑定和异步的，那么可以使用 Parallel.ForEachAsync 或 Polly.RateLimiting 基于 的 SemaphoreSlim 自定义帮助程序类。

结论

自定义TaskScheduler 只是一个工具，与任何工具一样，它可能被正确或错误地使用。如果您需要一个了解 UI 的调度程序，那TaskScheduler 适合您。但是，是否应该在应用中使用一个进行并发和并行控制？我会投反对票。如果团队可能在多年前有正当理由来使用，但请仔细检查这些理由今天是否存在。

是的，请记住，阻塞异步调用可能会以多种方式反噬，TaskScheduler 只是其中之一。因此，我建议对每个阻塞异步调用的地方进行备注，解释为什么您认为这样做既安全又有用。