5

我正在开发一个实现 IDisposable 接口的项目。在这个项目中，我发现我对 GarbageCollector 的了解可以说是很差。所以我开始阅读一些文档，最后在 MSDN 上找到了“垃圾收集基础”一文。

您必须了解，在这一点上，我一直认为 GarbageCollector 是在下水道工作的人，负责清理来自该计划的废物。因此，我很惊讶地阅读了以下片段：

垃圾收集器被 CLR 初始化后，它会分配一段内存来存储和管理对象。

一段之后，该文件指出：

为了保留内存，垃圾收集器调用 Win32 VirtualAlloc 函数，并一次为托管应用程序保留一段内存。垃圾收集器还根据需要保留段，并通过调用 Win32 VirtualFree 函数将段释放回操作系统（在清除它们的任何对象之后）。

如果我理解正确，GarbageCollector 实际上是.NET 程序的MemoryManager ！

我知道，它仍然会收集垃圾。但这不就像称歌手为麦克风支架一样吗？当然，这是真的，但这并不是你花钱去看他们的理由。GarbageCollector 显然不仅仅是废物处理，仅将其称为 GarbageCollector 似乎并不公平。

所以总而言之：

我理解正确吗？还是我走远了？

如果我理解正确：为什么.NET 开发人员称它为 GarbageCollector？

4

4 回答 4

4

它不仅仅是.NET。Java、C++、Objective-C 和其他语言也使用相同的术语。他们确实管理内存，但主要是为了清理留下的垃圾。

想一想，分配内存确实是一项相当微不足道的任务——VirtualAlloc大部分时间都在调用。真正的辛勤工作和科学来自于清理进程使用的内存。.NET GC 确实是一个高度优化的引擎，很多人在清理垃圾时花费了大量精力来优化 GC，例如处理内存中的固定对象、碎片堆、后台处理，以便它不会影响性能。

所以是的，你可以称它为 MemoryManager，但公平地说，它真正的明星技能是收集垃圾。

于 2013-07-17T08:27:14.503 回答
3

你是对的，垃圾收集器本质上是一种内存管理器。

如果您认为要使垃圾收集能够发生，那么这是有道理的，最实用的方法是垃圾收集机制和内存分配机制（以及引用解析策略，在压缩垃圾收集器的情况下）密切相关。

这样做的原因是垃圾收集器需要执行大量的簿记才能运行。为了可靠地执行该簿记，除其他事项外，它需要有关发生的分配的信息。最明显的实现方法是让垃圾收集器提供自己的内存分配例程。这可以通过提供一个新的内存分配器接口来替代该语言提供的标准接口（并可能利用它，正如 Marco 在评论中提到的那样），或者通过拦截并实质上替换该语言的标准内存分配器来完成它自己的。

在任何情况下，所有内存管理器都需要提供某种内存分配机制——所以这并不是它们的区别。但是，实际上只有少数可以自动收集垃圾，因此我们在命名那些可以自动收集垃圾时关注的就是这些。本质上，垃圾收集器实际上是指垃圾收集内存管理器。

现在它的通用名称可能确实听起来有点误导，但它不是 .NET 开发人员提出的。这种内存管理器一直被称为垃圾收集器，可能早在 Lisp 中最早出现这个概念时。我想，出于历史原因，它一直保持这种状态。

于 2013-07-17T08:26:42.000 回答
2

回收未使用内存的实体在 .Net 中称为垃圾收集器，这可能是因为自 50 到 60 年代自动内存管理的想法出现以来，它一直被称为垃圾收集器。

最初，管理应该在哪里分配内存的问题可能被认为是分开的，因为这也是手动内存管理所必需的。更深层次的问题是如何检测分配内存的哪些部分不再被程序“垃圾”使用，并释放它们以供重用。显然，如果您首先知道内存是如何分配的，这会更容易，因此您不妨将分配内存的责任交给 GC。

于 2013-07-17T08:25:28.390 回答
0

基本上是的，它是一个内存管理器，但同时它会删除未使用的对象以回收内存空间。在它删除垃圾对象后，它对对象进行排序/排列，以便在下一个内存位置创建新对象。

我建议你阅读“CLR via C#”一书，它对垃圾收集器有很好的解释。

于 2013-07-17T08:31:02.660 回答