本文 AI 含量 100%，全文由 GPT-5.4 创作

从单线程调度 Demo 理解 .NET 的线程调度、TaskScheduler、SynchronizationContext 与 await

在 .NET 异步编程中，最容易让人混淆的几个概念，往往正好是最核心的几个：

Thread
ThreadPool
Task
TaskScheduler
SynchronizationContext
await
continuation（续体）

这些名词如果零散地看定义，常常“每个字都认识，连起来却很模糊”。例如：

Task 到底是不是线程？
await Task.Delay(...) 为什么不会阻塞线程？
await 之后到底是“回到原线程”，还是“回到原上下文”？
SynchronizationContext.Current 是谁创建的？保存在哪里？
TaskScheduler 和 SynchronizationContext 到底是什么关系？
如果希望“所有工作都回到同一线程执行”，应该如何设计？

本文不打算对这些概念做碎片式解释，而是选择一个非常适合建立整体认知的案例：融合版单线程调度 Demo。

通过这个案例，可以把以下问题一次性串起来：

Task 是什么，线程又是什么
TaskScheduler 负责什么
SynchronizationContext 负责什么
await 的恢复机制是怎么工作的
为什么有些场景下 await 后能回到同一线程
单线程调度器与 UI 线程模型之间的相似性在哪里

一、先建立整体图景：谁是真正执行代码的，谁在负责“安排”代码？

在 .NET 中，可以先用下面这组关系建立直觉：

Thread（线程）：真正执行代码的载体
ThreadPool（线程池）：一组可复用线程
Task：一项工作，或一个未来会完成的操作
TaskScheduler：负责将 Task 安排到某个执行环境中
SynchronizationContext：负责将 continuation 投递回某个执行环境
Post：将回调异步投递给某个上下文
await：不是阻塞等待，而是把方法拆成前后两段，等待条件成熟后再恢复后半段代码

这其中最重要的一点是：

Task 不是线程，Task 表示“工作”；线程才是“真正跑代码的人”。

而当这项工作需要被安排执行时，TaskScheduler 出场。
当这项工作在 await 之后需要恢复执行时，SynchronizationContext 出场。

从职责上看，可以先给出一个简明总结：

TaskScheduler 负责“任务如何开始执行”
SynchronizationContext 负责“await 之后如何恢复��行”

理解了这一点，后面的很多机制都会顺理成章。

二、为什么要从“单线程调度 Demo”入手？

因为一个好的案例，往往比十个术语定义更有解释力。

如果只看抽象定义，很容易得到一些模糊印象：

TaskScheduler 负责调度
SynchronizationContext 也和调度有关
await 似乎又会“帮忙回去”

这些描述都不算错，但缺少结构。

而单线程调度 Demo 可以非常清楚地把机制拆开：

初始 Task 如何进入执行环境
await 之后 continuation 如何返回这个环境
为什么可以保证所有工作最终都在同一线程上串行执行

更重要的是，这个模型和 WinForms/WPF 这类 UI 线程模型在本质上非常接近，因此一旦吃透这个 Demo，再看 UI、线程池、异步恢复机制，理解会顺畅很多。

第一部分：主线概念 —— TaskScheduler 与 SynchronizationContext

三、Task 是“工作”，不是“线程”

先看一个最常见的例子：

Task.Run(() => Console.WriteLine("Hello"));

这行代码很容易让人误以为：

创建了一个 Task，所以就创建了一个线程。

实际上并不是。

这段代码真正表达的是：

创建一项工作
把它交给某个调度机制
最终由某个线程去执行

通常情况下，这项工作会被线程池中的某个线程执行。
所以这里存在两个完全不同的概念：

Task：工作或未来结果
Thread：执行工作的物理载体

这一区分非常重要。因为一旦把 Task 和线程混为一谈，后面关于 await、调度器、线程切换的很多问题都会越想越乱。

四、TaskScheduler：决定 Task 如何进入执行环境

TaskScheduler 是 TPL（Task Parallel Library）中的任务调度器抽象。

它回答的问题是：

一个 Task 应该如何被安排执行？

具体来说，它关心的是：

Task 进入哪个队列
谁来执行它
是否允许在当前线程 inline（就地）执行
调度策略是什么

默认情况下，TaskScheduler.Default 通常会基于线程池调度任务。
但 TaskScheduler 并不要求一定使用线程池。理论上完全可以自定义，例如：

限制并发数
强制所有任务进入同一个串行队列
把任务送到某一条专用线程
做一些特殊优先级调度

因此，TaskScheduler 的本质不是“线程”，而是：

将 Task 安排到某个执行环境中的规则与机制。

五、SynchronizationContext：决定 continuation 如何回到某个执行环境

与 TaskScheduler 不同，SynchronizationContext 的重心不在“任务最初如何开始”，而在：

一段需要稍后执行的回调，应该如何被投递到某个执行环境中？

这个抽象最典型的应用场景就是 await。

例如，一个方法在 UI 线程中执行：

await Task.Delay(1000);
UpdateUi();

为什么 UpdateUi() 往往还能安全地回到 UI 线程执行？

因为在 await 时，运行时捕获了当前的 SynchronizationContext；而当等待完成后，continuation 会通过这个上下文的 Post 被投递回去。

因此，SynchronizationContext 的本质可以理解为：

一个“如何把回调投递回某个环境”的抽象接口。

六、Post：把代码“发回去”的关键动作

SynchronizationContext 中最核心的方法之一是 Post。

它可以先简单理解为：

“请异步地帮我执行这段回调。”

例如：

context.Post(_ => DoSomething(), null);

这里表达的不是“立刻执行”，而是：

把回调交给 context
由 context 所代表的环境稍后执行

在不同上下文中，Post 的实现可以完全不同：

在 UI 上下文中，可能是排入 UI 消息队列
在自定义单线程上下文中，可能是加入内部工作队列
在其他上下文中，也可能是转发给线程池

因此，Post 的语义不是“执行”，而是：

投递、封送、排队。

理解 Post，就理解了 await 恢复机制的核心动作。

七、SynchronizationContext.Current 是什么？由谁创建？保存在哪里？

SynchronizationContext.Current 不是一个全局单例，也不是运行时自动为每个线程无条件生成的对象。
它更准确的含义是：

当前执行线程当前安装的同步上下文。

可以这样理解：

如果当前线程被某个框架、宿主或用户代码设置了 SynchronizationContext，那么 Current 就返回那个对象
如果没有设置，Current 通常是 null

常见来源包括：

WinForms/WPF 为 UI 线程安装自己的 SynchronizationContext
某些框架或测试宿主设置自己的上下文
用户代码主动调用 SynchronizationContext.SetSynchronizationContext(...)

从使用者角度，可以把 Current 理解成“与当前线程关联的当前上下文引用”。
它不是线程本身，但它常常与某条线程或某个事件循环绑定在一起。

第二部分：await 到底做了什么？

八、await 不是阻塞等待，而是“拆分方法”

看一个最简单的 async 方法：

async Task DemoAsync()
{
    Console.WriteLine("A");
    await Task.Delay(1000);
    Console.WriteLine("B");
}

从表面效果看，它像是“打印 A，等一秒，再打印 B”。
但从机制上看，更准确的描述是：

执行 await 之前的代码
发现 Task.Delay(1000) 尚未完成
将 await 后面的代码保存为 continuation
当前方法挂起并返回一个未完成的 Task
一秒后，delay 完成
continuation 被重新调度执行

也就是说：

await 的本质不是阻塞线程，而是拆分方法，把后半段交给将来的某个时刻恢复执行。

这也是异步编程能够节省线程资源的根本原因。

九、为什么 `await Task.Delay(...)` 不会一直占着线程？

Task.Delay(...) 是一个基于计时器的异步操作，它并不是让当前线程“睡眠 1 秒”。

当代码执行到：

await Task.Delay(1000);

时，真正发生的是：

当前 async 方法挂起
当前线程从这段方法中释放出来
计时器在后台计时
一秒后，delay 对应的 Task 完成
continuation 再被安排执行

因此，等待期间：

当前线程不会持续占用 CPU
不会做无意义的忙等
这条线程可以去执行别的工作

这正是异步 I/O 和同步阻塞之间的核心差异。

十、await 之后到底“回哪里”？

这是理解异步恢复机制时最关键的一点。

最常见但不够准确的说法是：

await 之后会回到原线程。

更准确的表述应该是：

await 之后会尝试恢复到先前捕获的执行上下文。

通常可以用以下顺序来理解：

优先考虑当前的 SynchronizationContext
如果没有，再看当前 TaskScheduler
如果也没有特殊要求，通常在线程池继续执行

因此，不同程序模型下表现会不同：

在 UI 程序中，经常表现为“回到原线程”
在控制台程序或线程池环境中，通常并不保证回到原线程
很多情况下，恢复到的是“线程池这个环境”，至于具体是哪条线程，不一定固定

这一点非常重要。
await 的恢复语义更接近“回到合适的执行环境”，而不是机械地“记住某个 Thread 对象”。

第三部分：融合版单线程调度 Demo

下面通过一个完整的融合版单线程调度 Demo，把这些抽象概念全部落地。

这个 Demo 的目标是：

初始任务由自定义 TaskScheduler 调度到同一条专用线程
await 之后的 continuation 由自定义 SynchronizationContext Post 回这条线程
所有工作最终都在这条专用线程上串行执行

它的结构不是两个各自拥有线程的独立实现，而是：

一个共享内核：线程 + 队列
两个适配器：
- TaskScheduler
- SynchronizationContext

也就是说：

一个队列，一条线程，两种入口。

十一、共享内核：SingleThreadPump

using System;
using System.Collections.Concurrent;
using System.Threading;

public sealed class SingleThreadPump : IDisposable
{
    private readonly BlockingCollection<Action> _queue = new();
    private readonly Thread _thread;

    public PumpSynchronizationContext SynchronizationContext { get; }

    public int ThreadId => _thread.ManagedThreadId;

    public SingleThreadPump(string threadName = "SingleThreadPump")
    {
        SynchronizationContext = new PumpSynchronizationContext(this);

        _thread = new Thread(Run)
        {
            IsBackground = true,
            Name = threadName
        };
        _thread.Start();
    }

    private void Run()
    {
        SynchronizationContext.SetSynchronizationContext(SynchronizationContext);

        foreach (var action in _queue.GetConsumingEnumerable())
        {
            action();
        }
    }

    public void Enqueue(Action action)
    {
        _queue.Add(action);
    }

    public bool IsOnOwnedThread =>
        Thread.CurrentThread.ManagedThreadId == _thread.ManagedThreadId;

    public void Dispose()
    {
        _queue.CompleteAdding();
    }
}

十二、事件循环：整个系统的“心脏”

SingleThreadPump 中最关键的一段代码是：

foreach (var action in _queue.GetConsumingEnumerable())
{
    action();
}

这就是一个标准的单线程事件泵。

它的行为可以概括为：

队列中有任务时：取出并执行
队列为空时：阻塞等待
调用了 CompleteAdding() 且队列已清空：循环自然结束

因此，这里虽然没有写 while (true)，但本质上已经是一个完整的“持续消费”循环。
更重要的是，它并不会在队列为空时忙等空转，而是高效地阻塞等待新工作到来。

所以，单线程调度器并不意味着“死循环吃满 CPU”，它完全可以是一个优雅且高效的阻塞式事件循环。

十三、在线程中安装 SynchronizationContext

在 Run() 中有一句非常关键的代码：

SynchronizationContext.SetSynchronizationContext(SynchronizationContext);

这句代码的意义是：

为这条专用线程安装当前同步上下文。

安装完成后，任何在这条线程上执行的 async 方法，在遇到 await 时，都能够读取到：

SynchronizationContext.Current

并捕获这个上下文。

这一步是“await 之后能回到这条线程”的前提。

十四、TaskScheduler：负责“初始任务如何进入这条线程”

using System.Collections.Generic;
using System.Threading.Tasks;

public sealed class PumpTaskScheduler : TaskScheduler
{
    private readonly SingleThreadPump _pump;

    public PumpTaskScheduler(SingleThreadPump pump)
    {
        _pump = pump;
    }

    protected override void QueueTask(Task task)
    {
        _pump.Enqueue(() => TryExecuteTask(task));
    }

    protected override bool TryExecuteTaskInline(Task task, bool taskWasPreviouslyQueued)
    {
        if (!_pump.IsOnOwnedThread)
            return false;

        return TryExecuteTask(task);
    }

    protected override IEnumerable<Task>? GetScheduledTasks()
    {
        return null;
    }
}

最关键的方法是 QueueTask：

protected override void QueueTask(Task task)
{
    _pump.Enqueue(() => TryExecuteTask(task));
}

它的意思非常直接：

有一个 Task 需要执行
不在当前线程直接跑
而是包装成一个 Action
送进 pump 的共享队列
最终由 pump 的专用线程执行

因此，PumpTaskScheduler 负责的是：

Task 如何被送入这个单线程执行环境。

十五、SynchronizationContext：负责“await 后如何回到这条线程”

using System.Threading;

public sealed class PumpSynchronizationContext : SynchronizationContext
{
    private readonly SingleThreadPump _pump;

    public PumpSynchronizationContext(SingleThreadPump pump)
    {
        _pump = pump;
    }

    public override void Post(SendOrPostCallback d, object? state)
    {
        _pump.Enqueue(() => d(state));
    }
}

这里最核心的是 Post：

public override void Post(SendOrPostCallback d, object? state)
{
    _pump.Enqueue(() => d(state));
}

它表达的是：

如果有一段回调需要投递回当前上下文
就把这段回调加入 pump 的队列
最终由 pump 线程执行

因此，PumpSynchronizationContext 负责的是：

continuation 如何被送回这个单线程执行环境。

十六、完整使用示例

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        using var pump = new SingleThreadPump();
        var scheduler = new PumpTaskScheduler(pump);
        var factory = new TaskFactory(scheduler);

        var task = factory.StartNew(async () =>
        {
            Console.WriteLine($"Before await, Thread = {Thread.CurrentThread.ManagedThreadId}");
            Console.WriteLine($"Has SyncContext = {SynchronizationContext.Current != null}");

            await Task.Delay(1000);

            Console.WriteLine($"After await, Thread = {Thread.CurrentThread.ManagedThreadId}");
            Console.WriteLine($"Has SyncContext = {SynchronizationContext.Current != null}");
        }).Unwrap();

        await task;
    }
}

如果实现正确，通常会看到：

Before await 与 After await 的线程 ID 相同
SynchronizationContext.Current 不为 null

这说明：

初始任务由自定义 TaskScheduler 送入了单线程环境
await 之后的 continuation 又通过自定义 SynchronizationContext 回到了同一线程

第四部分：运行时流程拆解

理解上面的代码之后，再把整个运行过程按时间顺序梳理一遍，整个模型就会非常清晰。

十七、步骤 1：创建单线程执行环境

using var pump = new SingleThreadPump();

这一步完成了以下事情：

创建一个共享队列
创建一条专用线程
创建一个 PumpSynchronizationContext
在线程启动后，把这个上下文设置为当前线程的 SynchronizationContext.Current

到这里，一个可承载异步恢复的单线程执行环境就准备好了。

十八、步骤 2：通过 TaskScheduler 调度初始任务

var scheduler = new PumpTaskScheduler(pump);
var factory = new TaskFactory(scheduler);

var task = factory.StartNew(async () => { ... }).Unwrap();

这一步的关键路径是：

StartNew(...) 创建一个 Task
这个 Task 被交给 PumpTaskScheduler
PumpTaskScheduler.QueueTask(...) 把它包装进队列
pump 线程从队列中取出并执行它

因此，async lambda 的前半段会在 pump 专用线程上运行。

十九、步骤 3：执行到 await

当代码执行到：

await Task.Delay(1000);

时，会发生这些事情：

Task.Delay(1000) 返回一个尚未完成的 Task
async 方法挂起
await 后面的代码被保存为 continuation
当前线程并不会阻塞等待
当前执行环境中的 SynchronizationContext.Current 被捕获下来

这里最关键的是第 5 步。
被捕获的不是“线程本身”，而是“一个知道如何把 continuation 投递回来的上下文对象”。

二十、步骤 4：等待期间线程在做什么？

很多人会误以为，代码执行到 await Task.Delay(1000) 后，那条线程会“等着 1 秒再继续”。

并不是。

真实情况是：

async 方法已经挂起
当前线程从这段方法中释放出来
这条线程可以去处理别的工作
如果当前没有别的工作，它就阻塞等待队列中的下一项任务

也就是说：

await 的等待期间，线程并没有被白白占着。

这一点对于理解异步编程非常重要。

二十一、步骤 5：delay 完成，continuation 被 Post 回来

一秒之后，Task.Delay(1000) 完成。
此时 continuation 需要恢复执行。

由于此前捕获了 PumpSynchronizationContext，因此恢复动作大致等价于：

capturedContext.Post(_ => continuation(), null);

也就是说：

continuation 不会直接随便找一条线程执行
它会通过 Post 被重新送回我们的 pump 队列
然后由 pump 专用线程取出并执行

这就是 SynchronizationContext 在 async/await 中的核心作用。

二十二、步骤 6：单线程环境执行 continuation

当 pump 线程再次从队列中取出 continuation 后，就会继续执行：

Console.WriteLine($"After await, Thread = {Thread.CurrentThread.ManagedThreadId}");

于是可以观察到，await 前后都运行在同一条线程上。

这里需要特别强调：

所谓“回到原线程”，本质上并不是运行时直接记住了某个 Thread 对象，而是记住了一个能把 continuation 投递回那个线程的 SynchronizationContext。

这是理解 .NET 异步恢复机制时最重要的细节之一。

第五部分：把这条主线彻底理顺

二十三、TaskScheduler 与 SynchronizationContext 的关系

从这个 Demo 可以非常清楚地看出：

`TaskScheduler`

负责：

任务最开始如何进入执行环境
进入哪个队列
由哪条线程最终执行

`SynchronizationContext`

负责：

continuation 如何被投递回执行环境
await 之后如何恢复

因此，在一个完整的单线程异步执行环境中：

初始任务靠 TaskScheduler 进入
续体任务靠 SynchronizationContext.Post 返回

两者不是同一个东西，但它们可以共用同一个基础设施：

同一个队列
同一条线程
同一个事件循环

这正是本文这个融合版 Demo 的设计核心。

二十四、为什么不应该把“回到原线程”当成默认假设？

因为 await 的恢复语义，严格来说不是“线程语义”，而是“执行环境语义”。

在不同上下文下，表现完全可能不同：

在 UI 程序中，常常回到原 UI 线程
在控制台程序中，可能回到线程池中的任意线程
在线程池环境里，即便前后线程 ID 相同，也可能只是巧合，而不是承诺

所以更准确的说法应该是：

await 默认尝试恢复到先前捕获的上下文；如果没有特殊上下文，通常继续在线程池中执行。

这比简单说“回到原线程”要准确得多。

二十五、这个 Demo 与 UI 线程模型的相似性

这个单线程调度 Demo 在本质上很像一个极简版 UI Dispatcher：

有一条固定线程
有一个消息/工作队列
有一个上下文对象负责把回调投递回去
所有对线程亲和对象的访问都封送回这条线程

这也是为什么理解了这个 Demo 之后，再看 WinForms/WPF 中的 UI 线程模型，会自然很多：

UI 线程就是那条“固定线程”
UI 消息队列就是那个“共享队列”
UI 的 SynchronizationContext 就是那个“投递 continuation 的路由器”

第六部分：常见误区

二十六、误区一：Task 就是线程

错误。

Task 是工作抽象，线程才是执行载体。
一个 Task 可以在线程池线程上执行，也可以在线程池外的专用线程上执行，甚至可以在异步等待期间根本不占用线程。

二十七、误区二：`await` 一定回到原线程

不准确。

更准确的说法是：

await 尝试恢复到先前捕获的上下文
有上下文时，可能表现为“回到原线程”
无特殊上下文时，通常只是继续在线程池执行，不保证原线程

二十八、误区三：`SynchronizationContext.Current != null` 就一定绑定某条固定线程

不一定。

关键不只是有没有 Current，还要看这个上下文对象的 Post 如何实现。

如果它的 Post 只是把回调丢回线程池，那 continuation 也未必回到同一线程。
真正决定行为的是上下文的实现策略，而不是 Current 这个属性本身。

二十九、误区四：单线程调度器就是 `while(true)` 空转

不是。

一个设计合理的单线程调度器通常采用阻塞式等待，例如：

foreach (var action in _queue.GetConsumingEnumerable())
{
    action();
}

当队列为空时，线程会阻塞等待，而不是忙等占满 CPU。
这类实现既简单又高效。

总结

理解 .NET 中的异步编程，关键不在于记住多少 API，而在于建立一套清晰的心智模型。

通过这个融合版单线程调度 Demo，可以把几个最核心的概念统一到一张图里：

Thread：真正执行代码的载体
Task：一项工作或未来结果
TaskScheduler：决定 Task 如何进入执行环境
SynchronizationContext：决定 continuation 如何返回执行环境
Post：将 continuation 投递回去的关键动作
await：拆分方法，在等待期间释放线程，条件满足后再恢复后半段

如果只用一句话概括本文的核心结论，可以是：

在 .NET 中，TaskScheduler 负责“任务怎么开始”，SynchronizationContext 负责“任务怎么回来”；理解了这一点，就抓住了 Task、线程调度与 await 恢复机制的骨架。

附加知识

下面这些内容不是本文主线，但与主题高度相关，适合作为补充理解。

1. 线程亲和性（Thread Affinity）

线程亲和性指的是：

某些对象或资源只能在特定线程上访问。

典型例子包括：

UI 控件
某些 COM 对象
某些 native 图形上下文或设备资源

单线程调度器之所以有价值，一个重要原因就是它天然适合承载这类“必须回到同一线程”的操作。

2. `TaskCreationOptions.LongRunning`

LongRunning 的含义通常是：

给调度器一个提示：这个任务可能会长期占用线程

在 TaskScheduler.Default 下，它往往意味着：

不使用普通线程池工作线程
而是新建一条专用线程来执行任务

但要注意：

它更适合同步、长期占线程的工作
对以 await 为主的异步 I/O 任务通常不合适
即使起始时在专用线程执行，await 之后也不会自动回到那条线程，除非有相应的上下文机制

3. `ThreadLocal<T>` 与 `AsyncLocal<T>`

这两个概念常常和“线程上下文”一起被提到，但它们并不是一回事。

`ThreadLocal<T>`

表示：

每个线程拥有自己独立的一份值。

适用于：

真正依赖固定线程的本地状态
每线程缓存
与线程绑定的对象

`AsyncLocal<T>`

表示：

每条异步调用链拥有自己独立的一份值。

适用于：

request id
trace id
日志上下文
与 async 流绑定的逻辑环境

可以简单记忆为：

ThreadLocal<T>：跟线程走
AsyncLocal<T>：跟异步流走

4. `ExecutionContext` 与 `SynchronizationContext` 的区别

这两个名字很像，但作用不同。

`SynchronizationContext`

关注的是：

continuation 往哪投递
await 后代码在哪里恢复执行

`ExecutionContext`

关注的是：

逻辑调用链上的环境数据如何流转
例如 AsyncLocal<T> 的值如何随异步流传递

换句话说：

SynchronizationContext 解决“去哪执行”
ExecutionContext 解决“执行时携带什么环境数据”

5. 为什么 `Task.Run(async () => ...)` 中 `await` 后不保证回原线程？

因为 Task.Run(...) 通常将工作放到线程池中执行，而线程池默认没有特殊的 SynchronizationContext。

所以像下面这样的代码：

await Task.Run(async () =>
{
    Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
    await Task.Delay(1000);
    Console.WriteLine(Thread.CurrentThread.ManagedThreadId);
});

前后线程 ID 可能相同，也可能不同。
如果相同，往往只是线程池恰好再次分配到了同一条线程，而不是恢复语义的保证。

6. 为什么 `GetConsumingEnumerable()` 很适合做事件泵？

因为它天然具备以下行为：

有元素时：消费并返回
没元素时：阻塞等待
已停止添加且队列清空时：自然结束

所以像这样：

foreach (var action in _queue.GetConsumingEnumerable())
{
    action();
}

就是一个非常简洁、非常适合单线程调度器的阻塞式事件循环写法。

原文链接: https://blog.jgrass.cc/posts/csharp-task-scheduler-synchronization-context/

本作品采用「署名 4.0 国际」许可协议进行许可，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。

理解 .NET 的线程调度、TaskScheduler、SynchronizationContext 与 await

从单线程调度 Demo 理解 .NET 的线程调度、TaskScheduler、SynchronizationContext 与 await

一、先建立整体图景：谁是真正执行代码的，谁在负责“安排”代码？

二、为什么要从“单线程调度 Demo”入手？

第一部分：主线概念 —— TaskScheduler 与 SynchronizationContext

三、Task 是“工作”，不是“线程”

四、TaskScheduler：决定 Task 如何进入执行环境

五、SynchronizationContext：决定 continuation 如何回到某个执行环境

六、Post：把代码“发回去”的关键动作

七、SynchronizationContext.Current 是什么？由谁创建？保存在哪里？

第二部分：await 到底做了什么？

八、await 不是阻塞等待，而是“拆分方法”

九、为什么 await Task.Delay(...) 不会一直占着线程？

十、await 之后到底“回哪里”？

第三部分：融合版单线程调度 Demo

十一、共享内核：SingleThreadPump

十二、事件循环：整个系统的“心脏”

十三、在线程中安装 SynchronizationContext

十四、TaskScheduler：负责“初始任务如何进入这条线程”

十五、SynchronizationContext：负责“await 后如何回到这条线程”

十六、完整使用示例

第四部分：运行时流程拆解

十七、步骤 1：创建单线程执行环境

十八、步骤 2：通过 TaskScheduler 调度初始任务

十九、步骤 3：执行到 await

二十、步骤 4：等待期间线程在做什么？

二十一、步骤 5：delay 完成，continuation 被 Post 回来

二十二、步骤 6：单线程环境执行 continuation

第五部分：把这条主线彻底理顺

二十三、TaskScheduler 与 SynchronizationContext 的关系

TaskScheduler

SynchronizationContext

二十四、为什么不应该把“回到原线程”当成默认假设？

二十五、这个 Demo 与 UI 线程模型的相似性

第六部分：常见误区

二十六、误区一：Task 就是线程

二十七、误区二：await 一定回到原线程

二十八、误区三：SynchronizationContext.Current != null 就一定绑定某条固定线程

二十九、误区四：单线程调度器就是 while(true) 空转

总结

附加知识

1. 线程亲和性（Thread Affinity）

2. TaskCreationOptions.LongRunning

3. ThreadLocal<T> 与 AsyncLocal<T>

ThreadLocal<T>

AsyncLocal<T>

4. ExecutionContext 与 SynchronizationContext 的区别

SynchronizationContext

ExecutionContext

5. 为什么 Task.Run(async () => ...) 中 await 后不保证回原线程？

6. 为什么 GetConsumingEnumerable() 很适合做事件泵？

九、为什么 `await Task.Delay(...)` 不会一直占着线程？

`TaskScheduler`

`SynchronizationContext`

二十七、误区二：`await` 一定回到原线程

二十八、误区三：`SynchronizationContext.Current != null` 就一定绑定某条固定线程

二十九、误区四：单线程调度器就是 `while(true)` 空转

2. `TaskCreationOptions.LongRunning`

3. `ThreadLocal<T>` 与 `AsyncLocal<T>`

`ThreadLocal<T>`

`AsyncLocal<T>`

4. `ExecutionContext` 与 `SynchronizationContext` 的区别

`SynchronizationContext`

`ExecutionContext`

5. 为什么 `Task.Run(async () => ...)` 中 `await` 后不保证回原线程？

6. 为什么 `GetConsumingEnumerable()` 很适合做事件泵？