基于作用域的内存管理的缺点

我真的很喜欢基于作用域的内存管理（SBMM）或RAII，因为它在C ++社区中更为常见（令人困惑？）。据我所知，除C ++（和C）外，当今没有其他主流语言使SBMM / RAII成为主要的内存管理机制，相反，他们更喜欢使用垃圾回收（GC）。

我觉得这很令人困惑，因为

1. SBMM使程序更具确定性（您可以确切地说出销毁对象的时间）；
2. 在使用GC的语言中，您通常必须执行手动资源管理（例如，参见关闭Java中的文件），这在一定程度上违背了GC的目的，并且也容易出错。
3. 堆内存还可以（非常优雅地称为imo）是作用域绑定的（请参见std::shared_ptrC ++）。

为什么SBMM没有得到更广泛的使用？它有什么缺点？

让我们首先假设内存比所有其他资源的总和（几十，数百甚至数千次）更为普遍。每个单个变量，对象，对象成员都需要分配一些内存，并在以后释放。对于打开的每个文件，您都会创建数十至数百万个对象来存储从文件中拉出的数据。每个TCP流与无限多个临时字节字符串一起创建，这些字符串将被写入流中。我们在同一页面上吗？大。

为了使RAII正常工作（即使您在阳光下也能为每个用例准备现成的智能指针），也需要正确拥有所有权。您需要分析谁应该拥有这个或那个对象，谁不应该拥有，以及何时应该将所有权从A转移到B。当然，您可以对所有内容使用共享所有权，但是随后您将通过智能指针模拟GC。到那时，将GC内置到语言中变得更加容易和快捷。

垃圾收集使您摆脱了对目前最常用的资源即内存的关注。当然，您仍然需要对其他资源做出相同的决定，但是这些资源很少见（见上文），复杂的（例如共享）所有权也很少见。精神负担大大减轻。

现在，您列举了一些缺点，使所有值都被垃圾回收。但是，将具有内存安全性的GC 和值类型与RAII集成到一种语言中是非常困难的，因此也许最好通过其他方法来减少这些折衷？

实际上，确定性的丧失并没有那么糟糕，因为它只会影响确定性对象的生存期。正如在下段中描述，大多数资源（除了存储器，这是丰富和可相当懒惰地再循环）的未绑定到在这些语言对象的寿命。还有其他一些用例，但在我的经验中很少见。

如今，您的第二点是手动资源管理，该声明通过执行基于作用域的清除，但并未将此清除与对象生命周期耦合在一起（因此不会与GC和内存安全性交互）而得到解决。在最新的Java版本中using，这是C＃，withPython中的try-with-resources。

RAII也遵循自动引用计数内存管理，例如Perl所使用的。尽管引用计数很容易实现，确定性和相当好的性能，但它不能处理循环引用（它们会导致泄漏），这就是为什么它不常用的原因。

垃圾收集的语言不能直接使用RAII，但通常会提供具有同等效果的语法。在Java中，我们有try-with-source语句

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

它.close()在块退出时自动调用资源。C＃具有IDisposable接口，可以.Dispose()在离开using (...) { ... }语句时调用该接口。Python具有以下with语句：

with open(filename) as f:
    ...

以类似的方式工作。有趣的是，Ruby的文件打开方法获得了回调。执行回调后，将关闭文件。

File.open(name, mode) do |f|
    ...
end

我认为Node.js使用相同的策略。

在我看来，垃圾收集最令人信服的优点是它允许可组合性。内存管理的正确性是垃圾回收环境中的本地属性。您可以单独查看每个部分，并确定它是否会泄漏内存。组合任意数量的内存正确零件，它们将保持正确状态。

当您依靠引用计数时，您将失去该属性。您的应用程序是否可以泄漏内存成为整个应用程序的全局属性（具有引用计数）。零件之间的每个新交互都有可能使用错误的所有权并破坏内存管理。

它对使用不同语言的程序设计有非常明显的影响。用GC语言编写的程序往往是对象的交互作用更多的对象，而在用无GC语言编写的程序中，人们倾向于选择结构化的部件，它们之间具有严格控制和有限的交互作用。

闭包是几乎所有现代语言的基本功能。它们非常容易用GC来实现，很难（尽管不是不可能）来使用RAII，因为它们的主要特征之一是它们允许您在变量的整个生命周期中进行抽象！

C ++仅在其他所有人都获得40年后才得到它们，并且许多聪明人花了很多辛苦才能使它们正确。相反，许多由在设计和实现编程语言方面知识为零的人设计和实现的脚本语言拥有它们。

1. SBMM使程序更具确定性（您可以确切地说出销毁对象的时间）；

对于大多数程序员而言，操作系统是不确定的，其内存分配器是不确定的，并且他们编写的大多数程序都是并发的，因此固有地是不确定的。对于绝大多数程序员而言，添加一个约束，要求在析构函数的确切位置而不是紧接在范围的末尾调用析构函数并不是一个重大的实际好处。

2. 在使用GC的语言中，您通常必须执行手动资源管理（例如，参见关闭Java中的文件），这在一定程度上违背了GC的目的，并且也容易出错。

参见usingC＃和useF＃。

3. 堆内存也可以（很优雅地称为imo）是作用域绑定的（请参阅C ++中的std :: shared_ptr）。

换句话说，您可以采用作为通用解决方案的堆并将其更改为仅在严重限制的特定情况下才能使用。当然是这样，但是没有用。

为什么SBMM没有得到更广泛的使用？它有什么缺点？

SBMM限制了您可以执行的操作：

1. SBMM 使用一流的词法闭包创建了向上的funarg问题，这就是为什么闭包在C＃等语言中很流行并且易于使用，而在C ++中却很少且棘手的原因。请注意，在编程中普遍存在使用功能构造的趋势。

2. SBMM需要析构函数，并且它们通过在函数返回之前增加更多工作来阻止尾部调用。尾部调用对于可扩展状态机很有用，并且由.NET等提供。

3. 众所周知，某些数据结构和算法很难使用SBMM来实现。基本上任何自然发生周期的地方。最值得注意的是图算法。您实际上可以最终编写自己的GC。

4. 并发编程比较困难，因为此处的控制流和对象生存期本质上是不确定的。消息传递系统中的实际解决方案往往是对消息进行深度复制以及使用过长的生命周期。

5. SBMM使对象保持活动状态，直到它们在源代码中的作用域结束为止，这通常比必要的时间更长，并且可以远远超过必要的时间。这增加了浮动垃圾（等待回收的无法到达的对象）的数量。相反，跟踪垃圾回收趋向于在最后一次引用对象消失之后不久释放对象，这可能会更快。请参阅内存管理神话：及时性。

SBMM的局限性如此之大，以至于程序员在无法进行生命周期嵌套的情况下需要一条逃生路线。在C ++中，shared_ptr提供了转义路径，但是它比跟踪垃圾回收慢约10倍。因此，使用SBMM而不是GC会使大多数人在大多数情况下处于错误的境地。但这并不是说它没有用。在资源有限的系统和嵌入式编程的背景下，SBMM仍然很有价值。

FWIW您可能想看看Forth和Ada，并继续阅读Nicolas Wirth的工作。

查看诸如TIOBE（当然可以争论，但是我想您可以使用它的问题）这种流行指数，您首先会发现前20名中约有50％是“脚本语言”或“ SQL方言” ”，其中“易用性”和抽象手段比确定性行为更为重要。在其余的“已编译”语言中，大约有50％的具有SBMM的语言和约50％的没有SBMM的语言。因此，当从计算中删除脚本语言时，我会说您的假设是错误的，在已编译的语言中，具有SBMM的语言与没有SBMM的语言一样受欢迎。

尚未有人提及的GC系统的主要优点之一是，只要存在，引用就可以保证保留其身份。如果在存在引用副本的情况下在对象上调用IDisposable.Dispose（.NET）或AutoCloseable.Close（Java），则这些副本将继续引用同一对象。该对象将不再有用，但是尝试使用该对象将具有可预测的行为，该行为由对象本身控制。相比之下，在C ++中，如果代码调用delete一个对象，然后又尝试使用它，则系统的整个状态将变得完全不确定。

还要注意的另一件事是，基于范围的内存管理对于拥有明确定义的所有权的对象非常有效。对于没有定义所有权的对象，它的效果不佳，有时甚至很糟糕。通常，可变对象应该具有所有者，而不可变对象则不需要所有者，但存在一个折衷：代码通过使用可变类型的实例来保存不可变数据是很常见的，这是通过确保不会暴露任何引用来实现的。可能会使实例变异的代码。在这种情况下，可变类的实例可能在多个不可变对象之间共享，因此没有明确的所有权。

首先，认识到将RAII等同于SBMM非常重要。甚至是SBRM。RAII的最基本（也是鲜为人知的或最受赞赏的）质量之一是，它使“成为一种资源”成为一种不影响合成的特性。

以下博客文章讨论了RAII的这一重要方面，并将其与使用非确定性GC的GC语言中的资源分配进行了对比。

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

需要注意的重要一点是，尽管RAII主要用在C ++中，但是Python（最后是非基于VM的版本）具有析构函数和确定性GC，可以将RAII与GC一起使用。如果是的话，两全其美。