为什么我应该使用异步操作而不是同步操作？

Question

我一直在思考这个问题。

假设我们有一个使用 HttpWebRequest 类的简单异步 Web 请求

class webtest1
{
    HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create("www.google.com");

    public webtest1()
    {
        this.StartWebRequest();
    }

    void StartWebRequest()
    {
        webRequest.BeginGetResponse(new AsyncCallback(FinishWebRequest), null);
    }

    void FinishWebRequest(IAsyncResult result)
    {
        webRequest.EndGetResponse(result);
    }
}

同步操作也可以轻松实现：

class webtest1
{
    HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create("www.google.com");

    public webtest1()
    {
        webRequest.GetResponse();
    }
}

那么，当一个更简单的同步操作就足够时，我为什么要使用更复杂的异步操作呢？节省系统资源？

Answer 1

如果您发出异步请求您可以在等待对请求的响应时做其他事情。如果您发出同步请求，您必须等待直到收到您的响应，然后才能执行其他操作。

对于简单的程序和脚本，这可能无关紧要，事实上在许多情况下，更容易编码和理解的同步方法将是更好的设计选择。

但是，对于非平凡的程序，例如桌面应用程序，同步请求会锁定整个应用程序直到请求完成导致不可接受的用户体验 .

Answer 2

同步操作会阻止您在等待请求完成或超时时执行任何其他操作。使用异步操作可以让您为用户制作动画以显示程序正忙，甚至让他们继续使用其他功能区域。

Answer 3

同步版本的代码更简单，但它掩盖了一个非常严重的问题。网络通信，或真正的 I/O 操作，可能会阻塞并持续很长时间。例如，许多网络连接的超时时间为 2 分钟。

同步执行网络操作意味着您的应用程序和 UI 将在该操作的整个持续时间内阻塞。一个常见的网络故障可能会导致您的应用程序阻塞几分钟而无法取消。这会导致客户非常不满意。

Answer 4

当您处理的事情多于核心时，异步变得特别有用 - 例如，您可能有许多活动的 Web 请求、许多文件访问操作、很少的 DB 调用，可能还有其他一些网络操作（WCF 或 redis 可能）。如果所有这些都是同步的，那么您将创建大量线程、大量堆栈，并遭受大量上下文切换。如果您可以使用异步 API，您通常可以在每个操作执行某事的短暂时刻利用池线程。这对于高吞吐量服务器环境非常有用。多核固然好，但效率更高。

在 C# 5 中，通过await，这与您的第二个示例相比没有更多的工作。

Answer 5

前几天我正在阅读这篇文章，之前曾思考过一个类似的问题：

Performance difference between Synchronous HTTP Handler and Asynchronous HTTP Handler

Answer 6

1) 您被困在一个单线程环境中，例如 silverlight。在这里你别无选择，只能使用异步调用，否则整个用户线程将被锁定。

2) 您有许多调用需要很长时间才能处理。当它可以继续执行并在等待返回时执行其他操作时，为什么要阻塞整个线程？例如，如果我有五个函数调用，每个调用需要 5 秒，我想立即启动所有函数并让它们在必要时返回。

3) 数据过多，无法在输出中同步处理。如果我有一个向控制台写入 10 GB 数据的程序并且我想读取输出，我就有机会异步地逐行处理。如果我同步执行此操作，则会耗尽缓冲区空间并锁定程序。