虽然这是一个老问题，但仍然有一个问题我没有看到任何人解决过:垃圾收集几乎不可能指定。

特别是，c++标准非常谨慎地根据外部可观察到的行为来指定语言，而不是实现如何实现该行为。然而，在垃圾收集的情况下，实际上没有外部可观察到的行为。

The general idea of garbage collection is that it should make a reasonable attempt at assuring that a memory allocation will succeed. Unfortunately, it's essentially impossible to guarantee that any memory allocation will succeed, even if you do have a garbage collector in operation. This is true to some extent in any case, but particularly so in the case of C++, because it's (probably) not possible to use a copying collector (or anything similar) that moves objects in memory during a collection cycle.

如果不能移动对象，就不能创建一个单独的、连续的内存空间来进行分配——这意味着您的堆(或自由存储区，或任何您喜欢称呼它的地方)可能会随着时间的推移而变得碎片化。这反过来又会阻止分配成功，即使空闲内存比请求的内存多。

尽管有可能提出某种保证，即(本质上)如果您重复完全相同的分配模式，并且它在第一次成功，那么它将在后续迭代中继续成功，前提是分配的内存在迭代之间变得不可访问。这是一个非常微弱的保证，基本上毫无用处，但我看不到任何加强它的合理希望。

即便如此，它也比为c++所提议的更强大。之前的提议[警告:PDF](被放弃了)根本不能保证任何东西。在28页的提案中，你在外部可观察到的行为中看到的是一个单一的(不规范的)注释:

[注意:对于垃圾收集程序，高质量的托管实现应该尝试最大限度地回收不可访问的内存量。-结束注释]

至少对我来说，这引发了一个关于投资回报的严肃问题。我们将破坏现有的代码(没有人知道具体破坏了多少，但肯定是相当多)，对实现提出新的要求，对代码提出新的限制，而我们得到的回报很可能是什么都没有?

即使在最好的情况下，我们得到的是基于Java测试的程序，以现在相同的速度运行可能需要大约6倍的内存。更糟糕的是，垃圾收集从一开始就是Java的一部分——c++对垃圾收集器施加了足够多的限制，以至于它几乎肯定会有更糟糕的成本/收益比(即使我们超出了提案所保证的范围，并假设会有一些收益)。

我要用数学方法总结一下情况:这是一个复杂的情况。数学家都知道，复数有两部分:实数和虚数。在我看来，我们这里的成本是真实的，但收益(至少大部分)是虚构的。

c++没有内置垃圾回收的最大原因之一是，让垃圾回收很好地使用析构函数是非常非常困难的。据我所知，还没有人真正知道如何完全解决这个问题。有很多问题需要处理:

deterministic lifetimes of objects (reference counting gives you this, but GC doesn't. Although it may not be that big of a deal). what happens if a destructor throws when the object is being garbage collected? Most languages ignore this exception, since theres really no catch block to be able to transport it to, but this is probably not an acceptable solution for C++. How to enable/disable it? Naturally it'd probably be a compile time decision but code that is written for GC vs code that is written for NOT GC is going to be very different and probably incompatible. How do you reconcile this?

这些只是面临的问题中的一小部分。

要回答关于c++的大多数“为什么”问题，请阅读c++的设计与进化

简短的回答: 我们不知道如何高效地(在很少的时间和空间开销下)并且始终(在所有可能的情况下)正确地进行垃圾收集。

长一点的回答: 就像C一样，c++是一种系统语言;这意味着当您编写系统代码时，例如操作系统时，将使用它。换句话说，c++就像C一样，以尽可能好的性能作为主要目标。该语言标准不会增加任何可能阻碍性能目标的特性。

这暂停了这个问题:为什么垃圾收集会影响性能?主要原因是，当涉及到实现时，我们(计算机科学家)不知道如何在所有情况下以最小的开销进行垃圾收集。因此，c++编译器和运行时系统不可能一直有效地执行垃圾收集。另一方面，c++程序员应该了解他的设计/实现，他是决定如何最好地进行垃圾收集的最佳人选。

最后，如果控制(硬件、细节等)和性能(时间、空间、电源等)不是主要的限制，那么c++就不是合适的工具。其他语言可能会更好，并提供更多[隐藏的]运行时管理，以及必要的开销。

所有的技术讨论都使这个概念过于复杂。

如果您将GC自动放入c++以获取所有内存，那么可以考虑使用类似web浏览器的东西。web浏览器必须加载完整的web文档并运行web脚本。web脚本变量可以存储在文档树中。在打开大量选项卡的浏览器中的大文档中，这意味着每次GC必须进行完整收集时，它还必须扫描所有文档元素。

On most computers this means that PAGE FAULTS will occur. So the main reason, to answer the question is that PAGE FAULTS will occur. You will know this as when your PC starts making lots of disk access. This is because the GC must touch lots of memory in order to prove invalid pointers. When you have a bona fide application using lots of memory, having to scan all objects every collection is havoc because of the PAGE FAULTS. A page fault is when virtual memory needs to get read back into RAM from disk.

因此，正确的解决方案是将应用程序分为需要GC的部分和不需要GC的部分。在上面的web浏览器示例中，如果文档树是用malloc分配的，但javascript是用GC运行的，那么每次GC启动时，它只扫描一小部分内存，并且文档树的内存中所有page OUT元素不需要被换回。

为了进一步理解这个问题，请查阅虚拟内存以及它是如何在计算机中实现的。这都是关于当没有那么多RAM时，程序可用2GB的事实。在32BIt系统的2GB RAM的现代计算机上，只要只有一个程序在运行，就不存在这样的问题。

作为另一个示例，考虑一个必须跟踪所有对象的完整集合。首先，您必须扫描所有通过根访问的对象。第二步扫描步骤1中可见的所有对象。然后扫描等待的析构函数。然后再次浏览所有页面，关闭所有不可见对象。这意味着许多页面可能会被多次换出和换回。

因此，我的回答是，由于触及所有内存而发生的PAGE FAULTS的数量导致对程序中所有对象进行完整的GC是不可行的，因此程序员必须将GC视为脚本和数据库工作的辅助，但使用手动内存管理进行正常工作。

另一个很重要的原因当然是全局变量。为了让收集器知道全局变量指针在GC中，它需要特定的关键字，因此现有的c++代码将无法工作。

为了增加争论。

关于垃圾收集有一些已知的问题，了解它们有助于理解为什么c++中没有垃圾收集。

1. 性能?

第一个抱怨通常是关于性能，但大多数人并没有真正意识到他们在谈论什么。正如马丁·贝克特(Martin Beckett)所指出的，问题可能不是表现本身，而是表现的可预测性。

目前有两个GC家族被广泛部署:

标记和清扫类 引用计数类型

标记和清除更快(对整体性能的影响较小)，但它患有“冻结世界”综合征:即当GC开始时，其他一切都停止，直到GC完成清理。如果您希望构建一个在几毫秒内响应的服务器……有些交易不会达到你的期望:)

The problem of Reference Counting is different: reference-counting adds overhead, especially in Multi-Threading environments because you need to have an atomic count. Furthermore there is the problem of reference cycles so you need a clever algorithm to detect those cycles and eliminate them (generally implement by a "freeze the world" too, though less frequent). In general, as of today, this kind (even though normally more responsive or rather, freezing less often) is slower than the Mark And Sweep.

I have seen a paper by Eiffel implementers that were trying to implement a Reference Counting Garbage Collector that would have a similar global performance to Mark And Sweep without the "Freeze The World" aspect. It required a separate thread for the GC (typical). The algorithm was a bit frightening (at the end) but the paper made a good job of introducing the concepts one at a time and showing the evolution of the algorithm from the "simple" version to the full-fledged one. Recommended reading if only I could put my hands back on the PDF file...

2. 资源获取初始化(RAII)

在c++中，将资源的所有权包装在对象中以确保它们被正确地释放是一种常见的习惯用法。它主要用于内存，因为我们没有垃圾回收，但它对许多其他情况也很有用:

锁(多线程，文件句柄，…) 连接(到数据库、另一台服务器……)

其思想是正确地控制对象的生命周期:

只要你需要，它就应该是活的 当你用完它的时候，它应该被杀死

GC的问题在于，如果它有助于前者，并最终保证以后……这个“终极”可能还不够。如果你释放一个锁，你真的希望它现在被释放，这样它就不会阻止任何进一步的调用!

带有GC的语言有两种解决方法:

当堆栈分配足够时不要使用GC:这通常是为了解决性能问题，但在我们的例子中，它确实有帮助，因为作用域定义了生命周期 使用构造…但它是显式(弱)RAII，而在c++中RAII是隐式的，因此用户不能在不知不觉中犯错误(通过省略using关键字)

3.智能指针

在c++中，智能指针通常是处理内存的灵丹妙药。我经常听到:我们根本不需要GC，因为我们有智能指针。

这是大错特错了。

智能指针确实有帮助:auto_ptr和unique_ptr使用RAII概念，确实非常有用。它们很简单，你可以很容易地自己写出来。

然而，当一个人需要共享所有权时，它变得更加困难:你可能在多个线程之间共享，并且在计数的处理上有一些微妙的问题。因此，很自然地使用shared_ptr。

这很棒，毕竟这就是Boost的用途，但它并不是万能的。事实上，shared_ptr的主要问题是它模拟了一个由引用计数实现的GC，但你需要自己实现周期检测…开始

当然有这个weak_ptr的东西，但不幸的是，我已经看到内存泄漏尽管使用shared_ptr，因为这些周期…当你在多线程环境中，它是非常难以检测的!

4. 解决方案是什么?

没有什么灵丹妙药，但一如既往，这绝对是可行的。在没有GC的情况下，需要明确所有权:

如果可能的话，最好在一个特定的时间拥有一个所有者 如果没有，请确保您的类图没有与所有权相关的任何循环，并通过weak_ptr的微妙应用来打破它们

所以，如果有一个GC…然而，这不是一个微不足道的问题。与此同时，我们只需要卷起袖子。