被阻塞的线程占用哪些资源?

8
使用异步编程模型(更具体地说,使用回调函数而不是阻止线程)的主要目的之一是最小化系统中阻塞线程的数量。
对于运行的线程来说,这个目标很明显,因为上下文切换和同步成本都会增加。
但是阻塞的线程呢?为什么减少它们的数量如此重要?
例如,在等待来自 web 服务器的响应时,线程被阻塞并且不占用任何 CPU 时间,也不参与任何上下文切换。
所以我的问题是:
除了 RAM(约1MB每个线程?)以外,阻塞线程还会占用哪些资源?
还有一个更主观的问题:
在什么情况下,这种代价真的能够证明写异步代码的麻烦是值得的(代价可能包括将你漂亮简洁的方法拆分成许多 beginXXX 和 EndXXX 方法,并将参数和局部变量移动到类字段中)。
更新-我没有提到或没有给予足够重视的其他原因:
1. 更多的线程意味着需要在公共资源上进行更多的锁定。 2. 更多的线程意味着更多线程的创建和销毁,这是昂贵的。 3. 系统肯定会耗尽线程/RAM,然后停止服务客户端(在 web 服务器场景下,这实际上可能会导致服务崩溃)。

争议:答案可能取决于上下文。例如,IIS工作线程是有限的资源,而操作系统线程则不太一样。提供更详细的信息会更有帮助。 - Craig Stuntz
我从未听说过将现有线程数量减少作为异步代码的目的。根据定义,异步代码依赖于比同步(单线程!)代码更多的线程。 - Harper Shelby
@Harper:不同意。 - Craig Stuntz
2
顺便提一下,默认情况下,IIS线程的堆栈仅为256Kb,而不是默认的1Mb。 - Daniel James Bryars
@Craig Stuntz:我的主要观点是,限制使用的线程数量并不是使用异步方法的理由。 - Harper Shelby
显示剩余7条评论
3个回答

6
除了RAM(每个线程约1MB)之外,阻塞线程所占用的资源还有哪些?
这是其中最大的一个。尽管如此,在.NET中线程池允许每个核心使用很多线程也是有原因的——在3.5中系统中每个核心默认为250个工作线程。(在.NET 4中,它取决于系统信息,例如虚拟地址大小、平台等——现在没有固定的默认值。)线程,特别是阻塞线程,真的不那么昂贵......
但是,从代码管理的角度来看,减少阻塞线程的数量是值得的。每个阻塞线程都应该在某个时候返回并变为非阻塞状态。拥有许多这样的线程意味着您必须管理相当复杂的代码。保持这个数字减少将有助于保持代码库更简单——更易维护。
在什么情况下,这种代价真的值得编写异步代码(代价可能是将你漂亮一致的方法分成许多beginXXX和EndXXX方法,并将参数和局部变量移动到类字段中)?
现在,它经常是一种痛苦。这很大程度上取决于场景。然而,在.NET 4中,Task<T>类极大地改善了许多情况下的编写异步代码的痛苦。使用TPL,它比以前使用APM(BeginXXX/EndXXX)或甚至EAP要容易得多。
这就是为什么语言设计者正在将来努力改善这种情况。他们的目标是使异步代码更容易编写,以便更频繁地使用它。

0

除了被阻塞线程持有的任何资源之外,线程池大小也需要考虑。如果您已经达到了最大线程池大小(如果我记得正确的话,对于.NET 4来说,每个CPU的最大线程数为100),那么您就无法在线程池上运行其他任务,直到至少有一个线程被释放。


@Reed:有趣——你能给我一个链接,让我可以了解更多吗?这是否意味着现在根本没有最大线程数了?当然,产生新线程至少会有启动成本。 - BrokenGlass
有一定的限制,但它基于系统地址空间。在x64上,例如,它是巨大的。关于CLR 4线程池的信息,请参见:http://aviadezra.blogspot.com/2009/06/net-clr-thread-pool-work.html和http://msdn.microsoft.com/en-us/magazine/ff960958.aspx。 - Reed Copsey

0
我想指出,堆栈内存的1MB数字(或256KB,或任何设置)是一个保留值;虽然它会减少可用地址空间,但实际内存只有在需要时才被提交。
另一方面,拥有大量线程必定会使任务调度器变得更加繁琐,因为它必须跟踪它们(自上次刻度以来已经变为可运行状态等等)。

4
在托管代码中这是不正确的,CLR会提交整个堆栈。有一篇Chris Brumme的博客文章记录了这一点。Joe Duffy也在他的博客中写过。寻找即可找到。 - Hans Passant
1
我之前不知道这个。在我看来,那很糟糕。 - 500 - Internal Server Error
1
这似乎也不再正确了。.Net Framework中线程的默认提交大小现在为100KB。然而,我找不到任何关于.Net Core行为的文档。使用64位地址空间,1MB的保留空间几乎是微不足道的。 - Mark

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接