TaskScheduler 在 C# 里到底是个什么角色？很多人第一反应是“定时器”。

其实它不管“几点执行”，而是决定 Task 在哪个线程上跑、怎么排队、能不能插队。

默认情况下用的是线程池（TaskScheduler.Default）。但你可以把它整个换掉——比如强制所有任务跑到 UI 线程上，或者限制最多 3 个并发，甚至独占一个后台线程顺序执行。

说白了，它就是任务调度系统的“中枢神经”。

为什么不能直接 new TaskScheduler()？

既然是个调度器，为什么不直接 new 一个？因为 TaskScheduler 是抽象类。

你必须继承它，然后实现三个核心方法：QueueTask、TryExecuteTaskInline、GetScheduledTasks。

缺一个编译就报错；写错了，运行时可能卡死、丢任务，或者线程数直接爆炸。

这三个方法各自负责什么？

• QueueTask(Task task)：任务进入队列的入口。你得把 task 存起来（比如丢进 BlockingCollection 或 ConcurrentQueue 里）。
• TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)：判断能不能“插队”，也就是直接在当前线程立刻执行。返回 true 表示抢跑成功，否则走正常的排队逻辑。UI 调度器通常用这个来判断当前是不是在主线程，如果是就直接执行，避免跨线程报错。
• GetScheduledTasks()：仅供调试使用（比如 Visual Studio 的“并行任务窗口”），可以返回空集合，但不能抛异常或阻塞。

最简可用的自定义调度器长什么样？

下面这个调度器只用一个专用线程顺序执行任务。非常适合需要强顺序、防并发、或隔离资源的场景（比如串口通信、文件写入队列）：

public class SingleThreadTaskScheduler : TaskScheduler, IDisposable
{
    private readonly BlockingCollection _taskQueue = new();
    private readonly Thread _workerThread;

    public SingleThreadTaskScheduler()
    {
        _workerThread = new Thread(WorkerLoop) { IsBackground = true };
        _workerThread.Start();
    }

    private void WorkerLoop()
    {
        foreach (var task in _taskQueue.GetConsumingEnumerable())
        {
            TryExecuteTask(task);
        }
    }

    protected override void QueueTask(Task task) => _taskQueue.Add(task);

    protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)
    {
        // 当前线程就是我们的专用线程？允许内联执行
        if (Thread.CurrentThread == _workerThread)
            return TryExecuteTask(task);
        return false;
    }

    protected override IEnumerable GetScheduledTasks() => _taskQueue.ToArray();

    public void Dispose()
    {
        _taskQueue.CompleteAdding();
        _workerThread.Join();
        _taskQueue.Dispose();
    }
}

注意：上面这个实现里，没加 IDisposable 和 CompleteAdding() 的话，程序退出时线程会卡住；没判空就调 TryExecuteTask，可能直接崩在空引用上。

什么时候该用 FromCurrentSynchronizationContext()？

这个函数只在 WPF/WinForms 主线程更新 UI 时才真正需要。它不是“自定义调度器”，而是 BCL 提供的现成调度器，背后封装了 SynchronizationContext。

常见的错误用法：Task.Run(() => { this.Text = "hello"; }, TaskScheduler.FromCurrentSynchronizationContext()) —— Task.Run 默认走线程池。FromCurrentSynchronizationContext() 必须在 UI 线程上调用才能捕获上下文，放在线程池里调等于白写。

正确姿势：在窗体构造或事件处理中（也就是 UI 线程）获取：var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();，然后再传给 Task.Factory.StartNew(..., uiScheduler)。

还有一个坑：WPF 中如果 TaskScheduler.Current 是 null，说明当前不在 UI 线程。FromCurrentSynchronizationContext() 会返回 null，不加判空直接调用就是空引用异常。

说到底，写一个自定义调度器本身并不难。真正难的是想清楚“我到底要控制什么”——是线程亲和性？并发数？执行优先级？还是任务生命周期管理？

目标一旦模糊，很容易写出又慢又难调试的调度器。比如用 Thread.Sleep 做轮询、用锁暴力保护队列、或者在 QueueTask 里同步等待资源。这些细节，往往比语法更决定成败。

《夸克》非常好用的免费AI浏览器

下载APP查看