【问题标题】:When GC.Collect() is called and frees up more than 3GB of space, is this necessarily a good thing?当调用 GC.Collect() 并释放超过 3GB 的空间时,这一定是一件好事吗?
【发布时间】:2019-11-15 11:23:04
【问题描述】:

我在这个网络上阅读了很多关于何时应该使用GC.Collect() 的问题,但没有一个能解决这个问题。

如果我们以某种方式设法使用它,例如它释放大量内存,这是否一定是一件好事,而不是简单地依靠垃圾收集器来管理内存?

无论我的 ASP.NET 应用程序保持多空闲,或者经过了多少时间,或者操作完成了多少,当显式调用 GC.Collect() 时被释放的内存永远不会被处理(只有它上面的内存,就像它某种缓存。)

我想到的一个理论是,也许那些 3GB+ 没有被释放(而是应用程序释放高于该阈值的内存)的原因可能是由于重用部分内存,或者可能是其他一些有用的优化,但代价是当然,在应用程序的整个运行时使用该内存。

有人可以就这些问题分享一些见解吗?只要有机会,我就会遵循最佳实践并处理对象。没有任何非托管资源需要最终确定 - 它始终由我处置。

编辑:使用的垃圾收集器是工作站,而不是服务器。

【问题讨论】:

    标签: c# asp.net .net garbage-collection .net-4.6


    【解决方案1】:

    The garbage collector's job is to simulate a machine with infinite memory. 如果您的系统有足够的未分配内存来继续运行,为什么收集器要花费 CPU 周期来执行识别未引用对象的艰苦工作?这是零收益的性能成本。

    如果不理会,当系统开始内存不足时,收集器将运行并释放这 3GB。在那之前它处于休眠状态。

    【讨论】:

    • 那么首先引入GC.Collect() 方法有什么意义呢?如果有的话,应该什么时候使用它?
    • 如果您知道现在是应用程序生命周期中花时间进行垃圾收集的好时机,您可以调用它。这对于游戏等实时应用程序可能很重要。它对于调试具有依赖句柄的应用程序中的引用泄漏也很有用。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-09-14
    • 1970-01-01
    • 2011-09-25
    • 2010-11-12
    • 2010-12-24
    • 1970-01-01
    • 2020-01-10
    相关资源
    最近更新 更多