.net - .NET 垃圾收集器的效率

Question

好的，这是交易。
有些人将自己的生命交给 .NET 的垃圾收集器，有些人根本不会相信它。

我是部分信任它的人之一，只要它不是非常关键的性能(我知道我知道..性能关键 + .net 不是受欢迎的组合)，在这种情况下，我更喜欢手动处理我的对象和资源。

我要问的是，是否有任何关于垃圾收集器在性能方面的效率或低效的事实？

请不要分享任何个人意见或基于经验的可能假设，我想要公正的事实。我也不想要任何赞成/反对的讨论，因为它不会回答这个问题。

谢谢

编辑:澄清一下，我基本上是在说:无论我们编写什么应用程序，资源是否重要，我们是否可以忘记一切并让 GC 处理它，或者我们不能吗？

我试图在现实中得到关于 GC 做什么和不做什么的答案，以及如果存在这种情况，手动内存管理会成功的地方可能会失败。它有限制吗？我不知道我怎么可能进一步解释我的问题。

我对任何应用程序都没有任何问题，这是一个理论问题。

Answer 1

对于大多数应用程序来说足够高效。但是您不必生活在对 GC 的恐惧中。在真正热的系统上，低延迟要求，您应该以完全避免它的方式进行编程。我建议你看看这个Rapid Addition White Paper :

Although GC is performed quite rapidly, it does take time to perform, and thus garbage collection in your continuous operating mode can introduce both undesirable latency and variation in latency in those applications which are highly sensitive to delay. As an illustration, if you are processing 100,000 messages per second and each message uses a small temporary 2 character string, around 8 bytes (this a function of string encoding and the implementation of the string object) is allocated for each message. Thus you are creating almost 1MB of garbage per second. For a system which may need to deliver constant performance over a 16 hour period this means that you will have to clean up 16 hours x 60 minutes x 60 seconds x 1MB of memory approximately 56 GB of memory. The best you can expect from the garbage collector is that it will clean this up entirely in either Generation 0 or 1 collections and cause jitter, the worst is that it will cause a Generation 2 garbage collection with the associated larger latency spike.

但请注意，避免 GC 影响之类的技巧是 真的很难 .您真的需要考虑您是否在性能要求中需要考虑 GC 的影响。