c# - 阻塞的线程占用了哪些资源

Question

在异步编程模型(更具体地说 - 使用回调而不是阻塞线程)中编写代码的主要目的之一是尽量减少系统中阻塞线程的数量。

对于运行线程，这个目标是显而易见的，因为上下文切换和同步成本。

但是阻塞的线程呢？为什么减少它们的数量如此重要？

例如，当等待来自网络服务器的响应时，线程被阻塞并且不占用任何 CPU 时间并且不参与任何上下文切换。

所以我的问题是:除了 RAM(每个线程大约 1MB？)阻塞的线程占用了哪些其他资源？

还有一个更主观的问题:在什么情况下，这种成本真的证明编写异步代码的麻烦是合理的(例如，代价可能是将你的良好连贯方法拆分为许多 beginXXX 和 EndXXX 方法，并将参数和局部变量移动到类字段)。

更新 - 我没有提到或没有给予足够重视的其他原因:

1. 更多线程意味着对公共(public)资源的更多锁定

2. 更多线程意味着更多线程的创建和处理，这是昂贵的

3. 系统肯定会用完线程/RAM，然后停止为客户端提供服务(在 Web 服务器场景中，这实际上会导致服务中断)

Answer 1

So my question is: other than RAM (about 1MB per thread ?) What other resources do blocked threads take-up?

这是最大的一个。话虽如此，.NET 中的 ThreadPool 允许每个内核有这么多线程是有原因的 - 在 3.5 中 the default was 250 worker threads per core in the system . (在 .NET 4 中，它取决于虚拟地址大小、平台等系统信息 - 现在没有固定的默认值。)线程，尤其是阻塞的线程，真的没有那么昂贵......

但是，我想说，从代码管理的角度来看，减少阻塞线程的数量是值得的。每个阻塞的线程都是一个操作，在某个时候应该返回并变得畅通。拥有许多这些意味着您需要管理相当复杂的代码集。减少这个数字将有助于使代码库更简单 - 并且更易于维护。

And another more subjective question: In what cases will this cost really justify the hassle of writing asynchronous code (the price could be, for example, splitting your nice coherent method to lots of beginXXX and EndXXX methods, and moving parameters and local variables to be class fields).

现在，这通常是一种痛苦。这在很大程度上取决于场景。 Task<T>然而，.NET 4 中的类在许多情况下极大地改进了这一点。使用 TPL，与以前使用 APM(BeginXXX/EndXXX)甚至 EAP 相比，痛苦要小得多。

这就是语言设计者为 improving this situation in the future 投入如此多精力的原因.他们的目标是使异步代码更易于编写，以便更频繁地使用它。