C 为什么要使用垃圾收集器？

可能重复：

嗨，我读了一些关于垃圾收集器的文章，但有一件事我还是不明白——为什么要使用垃圾收集器

我将尝试解释我的想法：

垃圾收集器应该将动态分配的内存释放回系统，以防不需要它，对吗？所以，如果你用C语言编写程序，你知道你是否需要一些内存，如果不需要，你可以简单地销毁它

---

那么，为什么要使用GC，而实际上您所需要做的只是明智地分配/释放内存？还是我遗漏了什么？谢谢。

你只需要聪明一点，没错；） 然而，如果您的设计不正确，那么可以很容易地监督一些事情

---

但是，使用垃圾收集，您不必关心内存，可以将更多精力放在程序的其余部分，因此可能会开发“更快”以提高效率。换句话说，程序员可以专注于编写针对其特定问题的独特位。

我同意mouviciel的评论。但是垃圾收集器确实允许更快的开发，因为开发人员不再需要担心内存泄漏，从而使他们能够专注于程序的其他方面

---

但请注意，如果您使用的是具有垃圾收集功能的语言编程，那么了解这一事实是非常明智的。理解它是如何工作的，以及它在后台做什么几乎是必须的（IMO）。

在复杂的项目中工作时，需要多次调用库和您没有编写的外部代码，跟踪需要释放的对象以及外部lib和代码中其他位置释放的对象变得非常困难

现在有很多工具可以使跟踪内存泄漏的任务变得更容易，但它们往往是潜藏的bug，只有在系统运行数小时或数天后才会被发现

---

不过，我同意你的看法。如果我可以控制代码库，我更喜欢在我负责的地方编写（比如c）。但是如果我必须与外部力量合作，那么有一个像样的垃圾收集器的东西会更有吸引力。

因为我们不再生活在80年代早期了。这是对开发人员时间的浪费，而且当您准备创建一个令人惊叹的应用程序时，关心最低级别的任务是很烦人的。

考虑一种情况，其中一个特定的指针由两个独立的子系统使用。一个子系统可能使用变量完成，程序员可能会想，“我已经完成了，我将继续并释放它”，完全不知道另一个子系统仍然需要访问它。或者另一个陷阱，开发人员认为，“我不确定是否有另一个子系统可能需要它”（即使没有），导致内存泄漏。这种情况在复杂系统中经常出现

所以，如果你用C语言编写程序，你知道你是否需要一些内存，如果不需要，你可以简单地销毁它

至少这是理论。问题是它会使代码变得非常复杂。例如，这：

for (x in ComputeBigList()) ...

变成这样

var xs = ComputeBigList();

try {
   for(x in xs) ...
} finally {
   FreeMemory(xs);
}

由于缺少垃圾收集器，我们需要命名

ComputeBigList

的结果，将其存储在变量中，然后添加一个包装在

中的delete语句，最后添加一个
，以确保它确实被删除

<>这是C++粉丝应该指出C++的保证析构函数调用可以使这更容易。也就是说，假设您希望对象能够逃逸创建它们的动态范围，那么您就有了与引用计数等相关的开销和附加代码。（即：我分配一个对象，然后返回它。）

GC做的另一件有用的事情是控制如何使用内存。重新定位GC允许您排列对象，以便更有效地访问它们。一般来说，GC为您的运行时提供了更大的灵活性，可以让您在何时支付回收内存的费用。（显式释放和引用计数更新始终必须立即进行。）
以避免错误。无论您在释放内存方面多么小心，要么最终会犯错误，要么最终会编写一个需要复杂内存引用模式的程序，这将使出错的可能性更大

在给定的足够时间内存在的任何可能性都将成为现实，最终您将使用手动方法泄漏内存，除非专门在监视内存消耗方面投入额外的精力。这一额外的工作将时间从编码转移到程序的主要目的，这可能不是为了管理内存

此外，即使您的程序没有泄漏内存，垃圾收集通常比许多非垃圾收集方法更有效地处理内存。大多数人不会
new
对象块来避免多次
new
调用，也不会在调用后重新访问和清理未使用的
new
对象的缓存。大多数手动垃圾收集方法集中于释放块边界处的内存，这可能会让垃圾停留的时间比需要的时间长一点

您在手动垃圾收集上增加的每一项好处和功能都使您离自动垃圾收集更近了一步。除了手动释放垃圾之外，不使用任何实用程序来收集垃圾将不容易扩展。要么您将花费大量时间检查内存分配/重新设置，要么您将不会花费足够的时间来避免内存泄漏

无论哪种方式，自动垃圾收集都可以为您解决这个问题，让您回到程序的要点。
这是一种反哑程序员的机制。相信我，当代码变得非常复杂时，当从动态分配内存的角度思考时，我们都是同样愚蠢的

<