【译】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 只是其中之一。因此，我建议对每个阻塞异步调用的地方进行备注，解释为什么您认为这样做既安全又有用。
