.NET Async 中的可扩展性与响应性答案

【问题标题】：Scalability versus Responsiveness in .NET Async.NET Async 中的可扩展性与响应性
【发布时间】：2014-01-17 21:04:31
【问题描述】：

我正在阅读Exam Ref 70-483: Programming in C# 这本书，并给出了以下代码示例：

清单 1-19

public Task SleepAsyncA(int millisecondsTimeout)
{
    return Task.Run(() => thread.Sleep(millisecondsTimeout);
}

public Task SleepAsyncB(int millisecondsTimeout)
{
    TaskCompletionSource<bool> tcs = null;
    var t = new Timer(delegate { tcs.TrySetResult(true); }, -1, -1);
    tcs = new TaskCompletionSource<bool>(t);
    t.Change(millisecondsTimeout, -1);
    return tcs.Task;
}

下面的段落说明了这一点：

SleepAsyncA 方法使用线程池中的一个线程，而睡眠。然而，第二种方法具有完全不同的实现，在等待时不占用线程要运行的计时器。第二种方法为您提供了可扩展性。

为什么 A 响应式但 B 可扩展？

【问题讨论】：

你能用你认为“响应式”的意思来编辑你的问题吗？
其实我也有点不确定。我能想到的唯一例子是 UI 没有被线程锁定。
这是本书的完整问题吗？有解释吗？第一种情况会使客户端 UI 更具响应性，第二种情况会使 Web 应用程序（服务器）更具可扩展性，但也会使客户端 UI 更具响应性，而第一种情况永远不会使 Web 应用程序更具响应性，并且会降低其可扩展性。
@PauloMorgado 这不是一个问题，而是直接从中提取了报价和样本。
@BanksySan，我能够下载该部分的示例章节（使用异步和等待）并阅读该部分多次。我还认为作者突然提出了可扩展性问题。整篇文章似乎只谈论客户端 UI，没有任何解释地介绍了服务器可扩展性。

标签： c# .net multithreading async-await scalability

【解决方案1】：

A 是响应式，因为它通过不阻塞对用户很重要的线程而具有异步性的外观。 UI 保持流畅，但不可扩展，因为在底层它占用了有限的资源（通过阻塞线程）。

B 仍然是响应式，但也是可扩展，因为它是真正异步的，而不是仅仅给出这样的外观。即使 UI 保持流畅，它也不会占用任何有限的资源。

【讨论】：

【解决方案2】：

假设起点没有进程/线程/任务控制并且是一个无响应的旋转循环，检查时间是否已经过去，例如：

public void SleepBadly(int millisecondsTimeout)
{
    var stopTime = DateTime.UtcNow.AddMilliseconds(millisecondsTimeout);
    while (DateTime.UtcNow < stopTime) {}
    return;
}

SleepAsyncA 使线程休眠而不是旋转，因此它不使用任何 CPU，因此会响应，因为 CPU 可用，但它仍在使用线程在它睡觉的时候。

SleepAsyncB 在等待时放弃线程，因此它不使用 CPU，并且该线程可以用于其他用途；所以它是响应式 和 可扩展。

例如，在规模上，如果您在 SleepAsyncA 中有 100,000 个未完成的调用；要么你会耗尽线程池并且它们会开始排队，要么你会拥有 100,000 个活动线程，这两者都不是很好的可伸缩性。

另一方面，SleepAsyncB 将使用 0 个线程，而 100,000 个调用正在等待，并且什么都不做比做某事具有无限的可扩展性。

但是，虽然 SleepAsyncB 是一个很好的示例，说明了如何使用 TaskCompletionSource 等任务结构，但您可能希望在此示例中实际执行以下操作：

public Task SleepAsyncC(int millisecondsTimeout)
{
    return Task.Delay(millisecondsTimeout);
}

【讨论】：