C# async/await延续执行线程与并发场景下的数据完整性问题

阿华AIGC实验室

2026-3-31

这个问题问得特别关键——async/await的线程调度和共享状态安全，确实是很多人刚上手异步编程时容易忽略的细节，咱们一步步理清楚：

一、await后的延续到底跑在哪个线程？

这里的核心是 SynchronizationContext（同步上下文），C#的async/await会根据当前线程的同步上下文来决定延续的执行线程：

如果当前线程存在SynchronizationContext（比如WPF/WinForms的UI线程、ASP.NET Core之前的ASP.NET请求上下文）：
await默认会把后续的延续代码“投递”回这个同步上下文，也就是回到原来调用DoThing()的线程（你说的线程A）执行ThingsDone++。这种情况下，延续是串行在原来的上下文线程上的，不会有并发问题——比如UI线程本身就是单线程，所有延续都排队执行。
如果当前线程没有SynchronizationContext（比如控制台程序、控制台后台服务，或者你在await时用了ConfigureAwait(false)）：
延续会直接跑在ThreadPool的任意线程上——可能是之前执行DoThingAsync()的线程B，也可能是线程池里的另一个空闲线程。这时候如果多次调用DoThing()且不等待（比如循环调用后WaitAll），多个延续就可能在不同线程上并行执行，这就会触发共享状态的并发修改问题。

二、你对同步的判断是对的，但要分场景处理

C# async/await没有任何“魔法”能自动保证共享数据的线程安全，是否需要同步完全取决于你的执行环境和调用方式：

场景1：需要同步的情况（必须加锁/原子操作）

当你在无同步上下文的环境中（比如控制台、后台服务），或者会并发触发多个DoThing()调用时（比如循环调用后WaitAll），await后的延续可能在多个线程上并行执行，这时候对共享状态（比如ThingsDone）的修改必须做同步处理。

你的lock版本是可行的，但对于int类型的自增，用更轻量的原子操作（Interlocked类）会更高效：

class ThingDoer
{
    // 用私有字段存储，确保原子操作的正确性
    private int _thingsDone;
    // 对外暴露时用Volatile.Read保证可见性（多线程读取时能拿到最新值）
    public int ThingsDone => Volatile.Read(ref _thingsDone);

    public async Task DoThing()
    {
        await DoThingAsync().ConfigureAwait(false); // 后台服务推荐用ConfigureAwait(false)避免捕获上下文

        // 用Interlocked.Increment实现原子自增，比lock更轻量
        Interlocked.Increment(ref _thingsDone);
    }

    private Task DoThingAsync()
    {
        // 模拟异步操作，比如IO请求、耗时计算等
        return Task.Delay(100);
    }
}

场景2：不需要同步的情况

如果你的代码运行在有同步上下文的环境（比如UI线程），且DoThing()只会被这个上下文线程调用（比如UI按钮点击事件），那么await后的延续会回到同一个UI线程执行，单线程环境下不会有并发修改问题，这时候就不需要加锁：

// UI线程下的示例（WPF/WinForms）
class ThingDoer
{
    public int ThingsDone { get; private set; }

    // 比如在WPF的Button_Click事件中调用，上下文是UI线程
    public async Task DoThing()
    {
        await DoThingAsync(); // 延续会回到UI线程
        ThingsDone++; // 单线程执行，无并发问题
    }

    private Task DoThingAsync()
    {
        return Task.Delay(100);
    }
}