如果已经在单独的线程上，是否有必要使用异步 Begin/End 方法？

Question

试图弄清楚我是否应该使用异步方法，例如：

• TcpListener.BeginAcceptTcpClient
• TcpListener.EndcceptTcpClient

和

• NetworkStream.BeginRead
• NetworkStream.EndRead，

而不是其同步 TcpListener.AcceptTcpClient 和 NetworkStream.Read 版本。我一直在查看相关线程，但我仍然对一件事有点不确定：

问题： 使用异步方法的主要优点是 GUI 不会被锁定。但是，这些方法将在单独的任务 线程本身，因此不存在这种威胁。此外，TcpListener.AcceptTcpClient 会阻塞线程，直到建立连接，这样就不会浪费 CPU 周期。既然是这样，那么为什么这么多人总是推荐使用异步版本呢？在这种情况下，同步版本似乎会更好？

此外，使用异步方法的另一个缺点是增加了复杂性和对象的不断转换。例如，必须这样做：

private void SomeMethod()
{
    // ...

    listener.BeginAcceptTcpClient(OnAcceptConnection, listener);
}

private void OnAcceptConnection(IAsyncResult asyn)
{
    TcpListener listener = (TcpListener)asyn.AsyncState;

    TcpClient client = listener.EndAcceptTcpClient(asyn);
}

与此相反：

TcpClient client = Listener.AcceptTcpClient();

另外，由于必须创建另一个线程，异步版本似乎会产生更多开销。 （基本上，每个连接都会有一个线程，然后在读取该线程时也会有另一个线程。Threadception！）

此外，还存在 TcpListener 的装箱和拆箱以及与创建、管理和关闭这些附加线程相关的开销。

基本上，通常只有单独的线程来处理单独的客户端连接，现在有了这样的线程，然后为执行的每种类型的操作（读取/写入流数据并侦听服务器端的新连接）提供了一个附加线程，

请纠正我如果我错了。我对线程还是新手，我正在尝试理解这一切。但是，在这种情况下，似乎使用普通的同步方法并且仅阻塞线程就是最佳解决方案？

Answer 1

TcpListener.AcceptTcpClient 会阻塞线程，直到建立连接，这样就不会浪费 CPU 周期。

但也没有任何工作完成。线程是一个非常昂贵的操作系统对象，几乎是最昂贵的。当线程因连接请求而阻塞时，您的程序正在消耗一兆字节的内存而未使用它。

但是，这些方法将在单独的任务线程上调用，因此不存在这种威胁

任务也不是一个好的解决方案的威胁，它使用线程池线程，但线程会阻塞。线程池管理器尝试保持正在运行的 TP 线程数等于机器上的 cpu 核心数。当 TP 线程长时间阻塞时，这将无法正常工作。它阻止其他等待轮到的 TP 线程完成其他有用的工作。

BeginAcceptTcpClient() 使用所谓的 I/O 完成回调。套接字侦听时不会消耗任何系统资源。一旦有连接请求到来，操作系统就会运行 APC（异步过程调用），它会获取线程池线程来进行回调。线程本身的使用时间通常为几微秒。非常高效。

在下一版本的 C# 中，使用下一个 async 和 await 关键字，此类代码将变得更加简单。年底吧，也许吧。

Answer 2

如果您在任何线程上调用AcceptTcpClient()，则在获得连接之前该线程将毫无用处。

如果调用BeginAcceptTcpClient()，调用线程可以立即停止，而不会浪费线程。

这在使用 ThreadPool（或 TPL）时尤其重要，因为它们使用有限数量的池线程。
如果有太多线程等待操作，则可能会耗尽线程池线程，因此新工作项必须等待其他线程之一完成。