async/await 对于真正的同步代码是无用的吗？

Question

我有一些代码需要读取网页（它是 XML）然后处理它。在我得到 XML 之前，我无能为力。

我正在执行一项任务的整个阅读和过程。但是在任务本身中，调用 HttpWebRequest.GetResponseAsync() 而不是 HttpWebRequest.GetResponse() 有什么好处吗？我无法将可取消的令牌传递给 GetResponseAsync()，因此在这种情况下，我认为我应该进行阻塞调用。

这是基于我（仍在学习）对等待的理解。据我了解：

1. 在异步方法上调用 await 意味着不要阻塞该方法并立即返回一个 Task 对象。
2. 对 Task 对象调用 await 意味着阻塞，直到任务完成或被取消。

更新： 我忘记了一条重要信息——这是任务中的代码。所以我已经没有阻止用户界面。问题是，在这个从功能上讲是一系列顺序操作的后台任务中，使用异步调用有什么价值吗？

Answer 1

我知道你在问await 的麻烦是什么时候异步代码按顺序执行步骤（即当一个函数既可以是异步函数又可以是非异步函数时）。

在您的示例中，使用HttpWebRequest（这是没有实际意义的，因为我们都应该使用HttpClient，但我离题了）：

传统的阻塞代码 - 假设这是一个 WinForms 上下文：

// (Error handling omitted for brevity)

void PopulateTextBox() {

    using( HttpWebRequest req = HttpWebRequest.CreateHttp( "https://www.bing.com" ) )
    using( HttpWebResponse res = (HttpWebResponse)req.GetResponse() )
    using( Stream body = res.GetResponseStream() )
    using( StreamReader rdr = new StreamReader( body ) )
    {
        this.textbox.Text = rdr.ReadToEnd();
    }
}

和异步代码等效：

// Note that HttpWebResponse does not have a `GetResponseStreamAsync()` method.
// (Error-handling and ConfigureAwait omitted for brevity)

async Task PopulateTextBoxAsync() {

    using( HttpWebRequest req = HttpWebRequest.CreateHttp( "https://www.bing.com" ) )
    using( HttpWebResponse res = (HttpWebResponse)( await req.GetResponseAsync() ) )
    using( Stream body = res.GetResponseStream() ) // HttpWebResponse does not have a `GetResponseStreamAsync()` method
    using( StreamReader rdr = new StreamReader( body ) )
    {
        this.textbox.Text = await rdr.ReadToEndAsync();
    }
}

鉴于所有不同的程序步骤都是按顺序进行的，因此很容易忽略异步代码的优势 - 但是：

1. await 不阻塞，线程让给调度程序（就像在 Windows 3.xx 天一样） - 允许 GUI 线程泵送窗口消息，允许处理您可能仍希望允许的 UX 事件并允许重绘窗口的程序（例如，如果用户在运行此方法时调整窗口大小）。同步代码不允许这样做，并且用户在暂时冻结的窗口中体验不佳 - 如果您曾经在低速或高延迟连接上使用过 Outlook 或 SQL Server Management Studio，您就会知道我在说什么，并且会降低用户对您产品质量的信心。

2. 您可以争论 w.r.t 冻结窗口“嗯，这就是 BackgroundWorker（或一般的后台线程）的用途！”是的 - 这就是它们在 2005 年被添加的原因，但问题是 它们无法扩展 。如果您有任何超出微不足道的应用程序的内容，则您无法为要完成的每个新的非 UI 冻结任务启动新的后台线程，因为 Windows 中的每个线程都会为您的进程的私有内存使用量增加超过一兆字节（由于默认堆栈大小）。通过使用在同一线程（或线程池中的现有线程）上运行的异步代码，您不会导致程序的内存增加。此外，在 Windows 上实例化线程也不是特别便宜。

   • 这就是为什么当今所有很酷的 Web 服务器和 Web 应用程序平台（如 Nginx、Node.JS、ASP.NET Core 等）都在异步 IO 上占很大比重，因为这意味着线程不会被阻塞 - 它会大量增加网络服务器可以同时处理的连接数。始于 1990 年代的“每个连接一个线程”的想法（具有讽刺意味的是，为了简化套接字编程）只是在遇到扩展问题时才使它变得复杂——因为那时一台 1990 年代后期的具有 256MB 内存的机器就不能处理 1,000 个同时连接而不会出现大量页面抖动，嗯！）
   • 有趣的笔记：For web-applications in IIS, the default thread size is 256KB。

回到HttpWebRequest 的例子，考虑到上述情况，以下优势变得显而易见：

• 与不使用任何“后台”功能（如BackgroundWorker，或后台线程，或async/await）相比：

  • 用户仍然可以与程序的 GUI 进行交互（即使您禁用控件以防止触发状态中断事件），例如调整窗口大小和重新绘制窗口。
  • Windows 不会告诉用户您的程序已“停止响应”。

• 与使用BackgroundWorker 或特别是后台线程相比：

  • 您不必处理每个BackgroundWorker 的设置和处理结果（它们出现在单独的事件处理程序方法中，而不是启动器中）。
    • 或者处理可变的类状态，因为BackgroundWorker 真的让你使用可变的Form/UserControl 状态，而且随着我多年来在 SWE 工作中获得的经验，我学会了厌恶 em> 可变状态（可变状态使并发可重入代码的工作变得非常困难）。
  • 由于没有创建新线程，内存使用减少。
  • 改进的规模：您可以触发数千个请求，您的程序会很好 - 但如果您使用后台线程触发一千个 HttpWebRequest 实例，您会遇到问题.

最后，HttpClient（我们都应该使用它而不是 HttpWebRequest）只有提供异步方法 - 所以你必须使用await（或ContinueWith，或IAsyncResult-适配器）来使用它。

Answer 2

是的，这毫无意义。我不明白为什么在需要使用返回值的单个线程中使用 async/await 会有所作为。选择的答案以 WinForms 为例，它可以演示阻塞，但是在服务器上处理 WEB 请求时，没有任何东西可以被“阻塞”，因为后续请求有自己的线程。