我注意到在异步 ASP.NET Web API Controller 方法中的 await 之后有一个意外的(我会说是冗余的)线程切换。

例如，下面我希望在位置 #2 和 3# 看到相同的 ManagedThreadId，但大多数情况下我在 #3 看到不同的线程:

public class TestController : ApiController
{
    public async Task<string> GetData()
    {
        Debug.WriteLine(new
        {
            where = "1) before await",
            thread = Thread.CurrentThread.ManagedThreadId,
            context = SynchronizationContext.Current
        });

        await Task.Delay(100).ContinueWith(t =>
        {
            Debug.WriteLine(new
            {
                where = "2) inside ContinueWith",
                thread = Thread.CurrentThread.ManagedThreadId,
                context = SynchronizationContext.Current
            });
        }, TaskContinuationOptions.ExecuteSynchronously); //.ConfigureAwait(false);

        Debug.WriteLine(new
        {
            where = "3) after await",
            thread = Thread.CurrentThread.ManagedThreadId,
            context = SynchronizationContext.Current
        });

        return "OK";
    }
}

我查看了 AspNetSynchronizationContext.Post 的实现，基本上可以归结为:

Task newTask = _lastScheduledTask.ContinueWith(_ => SafeWrapCallback(action));
_lastScheduledTask = newTask;

因此，延续被安排在 ThreadPool 上，而不是被内联。在这里，ContinueWith 使用 TaskScheduler.Current ，根据我的经验，它始终是 ASP.NET 中 ThreadPoolTaskScheduler 的一个实例(但它不是必须是那样，见下文)。

我可以使用 ConfigureAwait(false) 或自定义等待程序消除像这样的冗余线程切换，但这会带走 HTTP 请求的状态属性(如 HttpContext.Current)的自动流。

当前 AspNetSynchronizationContext.Post 的实现还有另一个副作用。 在以下情况下会导致死锁:

await Task.Factory.StartNew(
    async () =>
    {
        return await Task.Factory.StartNew(
            () => Type.Missing,
            CancellationToken.None,
            TaskCreationOptions.None,
            scheduler: TaskScheduler.FromCurrentSynchronizationContext());
    },
    CancellationToken.None,
    TaskCreationOptions.None,
    scheduler: TaskScheduler.FromCurrentSynchronizationContext()).Unwrap();

这个例子虽然有点做作，但显示了如果 TaskScheduler.Current 是 TaskScheduler.FromCurrentSynchronizationContext() 可能会发生什么，即从 AspNetSynchronizationContext 生成。它不使用任何阻塞代码，并且可以在 WinForms 或 WPF 中顺利执行。

AspNetSynchronizationContext 的这种行为不同于 v4.0 实现(它仍然作为 LegacyAspNetSynchronizationContext 存在)。

那么，这种变化的原因是什么？我想，这背后的想法可能是减少死锁的差距，但当前的实现仍然可能出现死锁，当使用 Task.Wait() 或Task.Result 。

IMO，这样说更合适:

Task newTask = _lastScheduledTask.ContinueWith(_ => SafeWrapCallback(action),
    TaskContinuationOptions.ExecuteSynchronously);
_lastScheduledTask = newTask;

或者，至少，我希望它使用 TaskScheduler.Default 而不是 TaskScheduler.Current 。

如果我在 LegacyAspNetSynchronizationContext 中启用 <add key="aspnet:UseTaskFriendlySynchronizationContext" value="false" /> 和 web.config，它会按预期工作:同步上下文安装在等待任务结束的线程上，并在那里同步执行延续。

最佳答案

continuation 被分派(dispatch)到一个新线程而不是内联是有意的。让我们分解一下:

1. 您正在调用 Task.Delay(100)。 100 毫秒后，底层任务将转换为完成状态。但是这种转换将发生在任意 ThreadPool/IOCP 线程上；它不会发生在 ASP.NET 同步上下文下的线程上。

2. .ContinueWith(..., ExecuteSynchronously) 将导致 Debug.WriteLine(2) 在将 Task.Delay(100) 转换为终止状态的线程上发生。 ContinueWith 本身将返回一个新任务。

3. 您正在等待 [2] 返回的任务。由于完成任务 [2] 的线程不受 ASP.NET 同步上下文的控制，异步/等待机制将调用 SynchronizationContext.Post。此方法始终约定为异步分派(dispatch)。

async/await 机制确实有一些优化来在完成线程上内联执行延续，而不是调用 SynchronizationContext.Post，但是只有当完成线程当前正在它即将分派(dispatch)到的同步上下文中运行时，该优化才会启动.在上面的示例中不是这种情况，因为 [2] 在任意线程池线程上运行，但它需要分派(dispatch)回 AspNetSynchronizationContext 以运行 [3] 继续。这也解释了为什么使用 .ConfigureAwait(false) 时不会发生线程跳跃:[3] 延续可以内联在 [2] 中，因为它将在默认同步上下文下分派(dispatch)。

关于您的其他问题:Task.Wait() 和 Task.Result，新的同步上下文不是旨在减少相对于 .NET 4.0 的死锁情况。 (事实上​​，在新的同步上下文中比在旧的上下文中更容易出现死锁。)新的同步上下文旨在实现 .Post() 与 async/await 机制配合良好，这旧的同步上下文在执行时悲惨地失败了。 (旧同步上下文的 .Post() 实现是阻塞调用线程，直到同步原语可用，然后分派(dispatch)内联回调。)

从未知完成任务的请求线程调用 Task.Wait() 和 Task.Result 仍然会导致死锁，就像在 Win Forms 中从 UI 线程调用 Task.Wait() 或 Task.Result或 WPF 应用程序。

最后，Task.Factory.StartNew 的怪异之处可能是一个真正的错误。但是，除非有一个实际的(非人为的)场景来支持这一点，否则团队不会倾向于对此进行进一步调查。

关于c# - AspNetSynchronizationContext 并等待 ASP.NET 中的延续，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23062154/