这里的快速问题：与 NetworkStream 类（由 TcpClient 生成）使用异步通信有什么明显的好处，即 BeginRead/BeginWrite 方法，而不是运行一个单独的线程并对其使用同步操作，即读/写？我的印象是（这很可能是完全错误的）异步操作是非阻塞的，并且在操作系统级别（可能在 TCP 堆栈中？）执行，并带有一个用于回调的线程池项。我认为它肯定与在同步方法上调用 ThreadPool.QueueUserWorkItem 不同，否则提供它就没有什么意义了。现在，我相当有信心这至少是文件 I/O 发生的事情（操作系统级调用），但如果有人能澄清有关网络（TCP）通信的问题，那将是最有帮助的。基本上，我想知道这两种方法是否有任何特定的好处（除了能够将 BinaryReader/StreamReader 类与同步调用一起使用这一显而易见的好处）。
【问题讨论】：
标签： .net networking sockets asynchronous tcp
有一个区别，如果你使用一个 Worker 线程来调用同步版本，你会在阻塞调用中占用一个线程。
Begin 方法不会占用线程，而是在适当的 I/O 信号上使用回调，然后回调将在池中的线程上运行。
【讨论】：
我同意 AnthonyWJones 的观点，假设您的线程池有 10 个线程，但您有 100 个被动足够的客户端。使用异步调用，您可以为其中的每一个调用 BeginRead，当来自某个调用的数据准备好时，它将由池线程之一处理。但如果您尝试使用 QueueUserWorkItem，您将安排仅从 10 个客户端接收数据。如果他们在 1 小时内什么都不发送，其他 90 个客户端将永远没有机会获取数据。
【讨论】：
我不太确定为什么 NetworkStream 甚至有 BeginRead/Write，因为这首先基本上违反了 NetworkStream 的目的。通过使用 Async 方法，您可以获得更快的响应、更大的可扩展性并减少资源消耗。
如果您一次只能有一个连接，那么是否使用线程池线程并不重要，但如果您接受许多连接，那么您肯定要使用异步。
【讨论】：
正如其他人所指出的，当您使用同步方法时，为您的进程分配另一个线程会影响您，因为您会增加同时连接的数量。
但是，如果您知道您只会有少量连接，我会说它变成了清洗，您应该选择最适合您的应用程序的方法。
在线程开销可以忽略不计的情况下，我希望这两种情况会像这样上演。
异步：
在另一个线程中同步：
这里唯一的区别是异步调用的第 4 步变成了另一个线程情况下的同步调用的第 1 步。
【讨论】：