ThreadPool和带有while(true)循环的方法

无论哪种方式，如果客户端保留，则使用相同数量的内存量联系。

到目前为止这是真的。这是由你的应用程序来决定它需要保留多少状态每个客户端。

如果它们保持连接，则线程不能被回收。如果是这样,那么ThreadPool将不会有太大的帮助，直到客户端断开连接打开一个线程来回收。

这是不正确的，因为它假设这些线程执行的所有有趣的操作都是同步的。这是一种简单的操作模式，事实上，现实世界的代码是异步的:线程调用请求一个操作，然后可以自由地做其他事情。当结果作为该操作的结果可用时，寻找其他事情要做的线程将运行对结果起作用的代码。

另一方面，有人建议我使用网络。BeginReceive和NetworkStream。EndReceive异步方法避免所有线程一起使用，以节省RAM使用和CPU使用。这是是真是假?

如上所述，像这样的异步方法将允许您使用少量的工作线程为潜在的非常多的客户端提供服务——但是它本身不会帮助或损害内存状况。

你是正确的。缓慢的阻塞代码会导致客户端和服务器端的性能都很差。您可以在单独的线程上运行缓慢的工作，这可能在客户端工作得很好，但在服务器端可能没有帮助。在服务器中使用阻塞方法可能会降低服务器的整体性能，因为它可能导致服务器上没有大量线程正在运行，并且所有线程都被阻塞。因此，即使是简单的请求也可能会花费很长时间。如果异步api可用于运行缓慢的任务，就像您所处的情况一样，那么最好使用异步api。(注意:即使异步操作不可用，也可以通过实现自定义的awaiter类来实现)这对客户端和服务器都更好。异步代码的主要目的是减少线程的数量。因为服务器可以同时处理更多的请求，因为减少线程数量来处理特定数量的客户端可以提高可伸缩性。

如果你不需要对线程或线程池有更多的控制，你可以使用异步方法。

而且，每个线程在堆上占用1 MB空间。因此，异步方法肯定有助于减少内存使用。然而，我认为您在这里描述的工作性质在多线程和异步方法中所花费的时间是差不多的。