Socket.*Async 方法是线程化的吗？

我目前正在尝试找出最小化 TCP 主服务器中使用的线程数量的最佳方法，以便最大限度地提高性能。

由于我最近阅读了大量 C# 5.0 的新异步功能，异步并不一定意味着多线程。这可能意味着将有限状态对象分成较小的块，然后通过交替与其他操作一起进行处理。但是，我不知道如何在网络中完成此操作，因为我基本上是在“等待”输入（来自客户端）。

因此，我不会对所有套接字使用 ReceiveAsync()，它只是连续创建和结束线程（假设它does创建线程）。

因此，我的问题或多或少是：主服务器可以采用哪种架构而不需要每个连接一个“线程”？

关于额外酷点的附带问题：考虑到线程数量超过处理核心数量只会使机器“假”多线程，就像任何其他异步方法一样，为什么拥有多个线程是不好的？

不，您不一定要创建线程。有两种可能的方法可以实现异步，而无需一直设置和拆除线程：

1. 您可以拥有“少量”长寿命线程，并在没有工作要做时让它们休眠（这意味着操作系统永远不会安排它们执行，因此资源消耗最小）。然后，当工作到达时（即调用异步方法），唤醒其中一个并告诉它需要做什么。很高兴认识你，托管线程池 http://msdn.microsoft.com/en-us/library/0ka9477y.aspx.
2. 在Windows中，最有效的异步机制是I/O 完成端口 http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx它同步对 I/O 操作的访问并允许少量线程管理大量工作负载。

关于多线程：

拥有多个线程对性能来说并不坏，if

• 线程数不要过多
• 线程不会使 CPU 过度饱和

如果线程数量过多，那么显然我们会给操作系统带来负担，因为必须跟踪和调度所有这些线程，这会耗尽全局资源并减慢速度。

如果线程受 CPU 限制，那么操作系统将需要执行更频繁的上下文切换以保持公平性，而上下文切换会降低性能。事实上，与用户模式线程 http://msdn.microsoft.com/en-us/library/ms682661.aspx（所有高度可扩展的系统都使用 RDBMS）我们让我们的生活变得更加困难，只是为了避免上下文切换。

Update:

我刚刚发现这个问题 https://stackoverflow.com/q/1285774/50079，这支持了这样的立场：你不能事先说有多少线程太多——有太多的未知变量。