C++中的垃圾回收 -- 为什么？

垃圾回收使得RCU无锁同步更易于正确高效地实现。

垃圾回收实际上是自动资源管理的基础。使用GC会改变解决问题的方式，这种方式很难量化。例如，当您进行手动资源管理时，您需要考虑以下问题：

• 考虑何时可以释放项目（所有模块/类是否都已完成？）
• 考虑在资源准备好释放时谁负责释放资源（哪个类/模块应该释放此项？）

在简单情况下，没有复杂度。例如，在方法开始时打开文件并在结束时关闭它。或者调用者必须释放返回的内存块。
当您有多个与资源交互的模块且不清楚谁需要清除时，事情很快变得复杂起来。最终结果是，解决问题的整个方法包括某些编程和设计模式，这是一种折衷。
在具有垃圾回收的语言中，您可以使用一次性模式，以便您可以释放您已经完成的资源，但如果您未能释放它们，则GC将拯救您的一天。

---

智能指针实际上是我提到的妥协的完美例子。除非你有备份机制，否则智能指针无法防止您泄漏循环数据结构。为了避免这个问题，您通常会妥协并避免使用循环结构，即使它可能是最合适的选择。

在支持GC的框架中，对于像字符串这样的不可变对象的引用可以和原始值一样被传递。考虑下面的类（C#或Java）：

public class MaximumItemFinder
{
  String maxItemName = "";
  int maxItemValue = -2147483647 - 1;

  public void AddAnother(int itemValue, String itemName)
  {
    if (itemValue >= maxItemValue)
    {
      maxItemValue = itemValue;
      maxItemName = itemName;
    }
  }
  public String getMaxItemName() { return maxItemName; }
  public int getMaxItemValue() { return maxItemValue; }
}

请注意，此代码与任何字符串的内容都没有关系，可以将它们视为基元。例如，像maxItemName = itemName;这样的语句可能会生成两条指令：一个寄存器加载后跟着一个寄存器存储。 MaximumItemFinder 不知道调用者是否会保留传入字符串的任何引用，而调用者也无法知道 MaximumItemFinder 将保留对它们的引用多长时间。调用getMaxItemName 的调用者无法知道 MaximumItemFinder 和返回的字符串的原始供应商是否已放弃所有对它的引用。但是，由于代码可以像传递原始值一样传递字符串引用，因此这些事情都不重要。
请注意，虽然上面的类在同时调用AddAnother时不是线程安全的，但是任何对GetMaxItemName的调用都保证返回一个有效的引用，可以是空字符串或已传递给AddAnother的字符串之一。如果想确保最大项名称和其值之间的任何关系，则需要进行线程同步，但是即使没有线程同步，内存安全性也得到了保证。
我认为没有办法编写像上面那样的方法，在任意多线程使用的情况下保持内存安全性，而不使用线程同步或者要求每个字符串变量都有自己内容的副本，保存在自己的存储空间中，在变量的生命周期内可能不会被释放或重定位。当然，也不可能定义一个字符串引用类型，它可以像int那样便宜地定义、赋值和传递。

垃圾回收可能会使泄漏成为你最可怕的噩梦

处理循环引用等事项的完整GC在ref-counted shared_ptr方面会有所升级。我在C++中也欢迎这种方式，但不是在语言层面上。

C++的美妙之一在于它不会强制进行垃圾回收。

我想纠正一个常见的误解：垃圾回收神话，认为它可以消除泄漏。根据我的经验，在与通过资源密集型主机应用程序使用垃圾回收等语言编写的代码进行调试时，最令人头痛的是逻辑泄漏。

谈论GC等主题时，有理论和实践之分。理论上，它很棒并且可以防止泄漏。然而，在理论层面上，每种语言都是美好的且无泄漏的，因为在理论上，每个人都会编写完全正确的代码，并测试每种可能出现问题的情况。

垃圾回收与不太理想的团队协作相结合，在我们的情况下导致了最糟糕、最难以调试的泄漏。

问题仍然与资源所有权有关。当涉及到持久对象时，您必须在这里做出明确的设计决策，而垃圾回收使人们很容易认为不需要这样做。

在开发人员没有始终进行交流和仔细审查彼此代码的情况下（在我的经验中非常普遍），在团队环境中给定某些资源R，开发人员A很容易存储对该资源的句柄。开发人员B也是如此，可能以间接方式将R添加到某个数据结构中。C也是如此。在垃圾回收的系统中，这已经创建了3个R的所有者。

因为开发人员A最初创建了该资源并认为自己是其所有者，所以当用户表示不再需要使用它时，他记得释放对R的引用。毕竟，如果他未能这样做，什么都不会发生，并且从测试中可以明显看出用户端移除逻辑未起作用。因此，他记得释放它，就像任何合理的开发人员一样。这触发了一个事件，B处理它并且也记得释放对R的引用。

然而， C 忘记了。他不是团队中更强的开发人员之一：一个相对新的招募者，只在系统中工作了一年。或者他甚至不在团队中，只是一个受欢迎的第三方开发人员，为我们的产品编写插件，许多用户将其添加到软件中。使用垃圾回收时，这就是我们获得那些静默逻辑资源泄漏的时候。它们是最糟糕的类型：它们不一定会在软件的用户可见侧面表现为明显的错误，除了在运行程序的持续时间内，内存使用量只是继续上升，目的不明。试图用调试器缩小这些问题可能会像调试时间敏感的竞争条件一样有趣。
如果没有垃圾回收，开发人员C将创建一个悬空指针。他可能会尝试在某个时候访问它，并导致软件崩溃。现在那是一个测试/用户可见的错误。 C 有点尴尬，并纠正了他的错误。在GC场景下，仅仅尝试找出系统在哪里泄漏可能是如此困难，以至于其中一些泄漏永远不会被纠正。这些不是valgrind-类型的物理泄漏，可以很容易地检测到，并指向特定的代码行。
使用垃圾回收，开发人员C创建了一个非常神秘的泄漏。他的代码可能会继续访问现在只是软件中一些不可见的实体的R，此时与用户无关，但仍处于有效状态。随着C的代码创建更多的泄漏，他正在创建更多的隐藏处理不相关资源的过程，软件不仅泄漏内存，而且每次都变得越来越慢。
因此，垃圾回收并不一定可以缓解逻辑资源泄漏。在不理想的情况下，它可能使泄漏变得更加容易而不被察觉，并保留在软件中。开发人员可能会因为尝试追踪他们的GC逻辑泄漏而感到沮丧，以至于他们只是告诉他们的用户定期重新启动软件作为解决方法。它确实消除了悬空指针，在安全至上的软件中，在任何情况下崩溃都是完全不可接受的，那么我更喜欢GC。但我经常在不那么安全关键但资源密集、性能关键的产品中工作，在那里，可以迅速修复的崩溃比真正晦涩和神秘的静默错误更可取，而且资源泄漏并不是微不足道的错误。
在这两种情况下，我们谈论的是不驻留在堆栈上的持久对象，例如3D软件中的场景图、合成器中可用的视频剪辑或游戏世界中的敌人。当资源将它们的生命周期绑定到堆栈时，无论是C++还是任何其他GC语言，都很容易管理资源。真正的困难在于持久资源引用其他资源。
在C或C++中，如果未明确指

我也怀疑C++委员会是否会将全面的垃圾回收机制添加到标准中。

但是我认为，现代语言中添加/拥有垃圾回收的主要原因是，反对垃圾回收的好理由太少了。自80年代以来，内存管理和垃圾回收领域取得了几项重大进展，我相信甚至有一些垃圾回收策略可以给您提供软实时保障（例如，“在最坏情况下GC不会超过...”）。

使用RAII和智能指针可以消除它的需要，对吗？
智能指针可以用于在C++中实现引用计数，这是一种垃圾回收（自动内存管理）的形式，但生产环境下的GC不再使用引用计数，因为它有一些重要的缺陷。
参考计数会泄露循环。考虑A↔B，两个对象A和B互相引用，因此它们的引用计数都为1，都不会被回收，但它们应该都被回收。高级算法如试验删除可以解决这个问题，但会增加很多复杂性。使用weak_ptr作为解决方法是退回到手动内存管理。
天真的参考计数由于几个原因而变慢。首先，它需要经常增加缓存外的引用计数（参见Boost's shared_ptr up to 10× slower than OCaml's garbage collection）。其次，在作用域末尾注入的析构函数可能会导致不必要且昂贵的虚函数调用，并阻止优化，例如尾调用消除。
基于作用域的参考计数会保留浮动垃圾，因为对象直到作用域结束才被回收，而跟踪GC可以在它们变得不可达时立即回收它们，例如一个在循环之前分配的局部变量是否可以在循环期间被回收？
一个有经验的C++开发者可以从垃圾回收中获得哪些优势？
生产力和可靠性是主要的好处。对于许多应用程序来说，手动内存管理需要程序员付出大量的努力。通过模拟无限内存机器，垃圾回收使程序员摆脱了这种负担，使他们能够专注于问题解决，并避免了一些重要的错误类别（悬空指针、缺失的free、双重free）。此外，垃圾回收还促进了其他形式的编程，例如通过解决上行funarg问题 (1970)。