为什么没有引用计数+ C# 中的垃圾收集？

Question

我有 C++ 背景，并且使用 C# 已有大约一年的时间。 和许多其他人一样，我对为什么确定性资源管理没有内置到该语言中感到困惑。 我们没有确定性析构函数，而是使用了 dispose 模式。 人们开始怀疑通过他们的代码传播 IDisposable 癌症是否值得付出努力。

在我偏向 C++ 的大脑中，使用带有确定性析构函数的引用计数智能指针似乎是垃圾收集器的一个重大进步，垃圾收集器要求您实现 IDisposable 并调用 dispose 来清理非内存资源。 诚然，我不是很聪明……所以我问这个纯粹是出于想更好地理解为什么事情是这样的愿望。

如果 C# 被修改为：

对象是引用计数的。 当对象的引用计数变为零时，系统会在该对象上确定性地调用资源清理方法，然后将该对象标记为进行垃圾回收。 垃圾收集发生在未来某个不确定的时间，此时内存将被回收。 在这种情况下，您不必实现 IDisposable 或记得调用 Dispose。 如果有非内存资源需要释放，则只需实现资源清理功能即可。

• 为什么这是一个坏主意？
• 这会违背垃圾收集器的目的吗？
• 实施这样的事情是否可行？

编辑： 从到目前为止的评论来看，这是一个坏主意，因为

1. GC 更快，没有
2. 处理对象图中循环的引用计数问题，

我认为第一是有效的，但第二是使用弱引用很容易处理。

那么，速度优化是否超过了以下缺点：

1. 可能无法及时释放非内存资源
2. 可能会过早释放非内存资源

如果您的资源清理机制是确定性的并且内置于语言中，您可以消除这些资源的可能性。

Answer 1

C++ 风格的智能指针引用计数和引用计数垃圾回收之间存在差异。 我还在我的博客 但这里有一个快速总结：

C++ 风格引用计数：

• 递减时的无界成本：如果大型数据结构的根递减到零，则释放所有数据的成本是无界的。

• 手动循环收集：为了防止循环数据结构泄漏内存，程序员必须通过用弱智能指针替换部分循环来手动破坏任何潜在的结构。 这是潜在缺陷的另一个来源。

引用计数垃圾收集

• 延迟RC：对于堆栈和寄存器引用，对象引用计数的更改将被忽略。 相反，当触发 GC 时，这些对象将通过收集根集来保留。
  对引用计数的更改可以推迟并批量处理。 这会导致更高的吞吐量。

• 合并：使用写屏障可以合并 更改引用计数。 这使得忽略对象引用计数的大部分更改成为可能，从而提高频繁变异引用的 RC 性能。

• 循环检测：对于完整的 GC 实现，还必须使用循环检测器。 然而，可以以增量方式执行循环检测，这又意味着 GC 时间有限。

基本上，可以为 Java 的 JVM 和 .net CLR 运行时等运行时实现基于 RC 的高性能垃圾收集器。

我认为跟踪收集器的使用部分是出于历史原因：引用计数方面的许多最新改进都是在 JVM 和 .net 运行时发布之后出现的。 研究工作转变为生产项目也需要时间。

确定性资源处置

这几乎是一个单独的问题。 .net 运行时使用 IDisposable 接口使这成为可能，如下例。 我也喜欢Gishu的答案。

---

@Skrymsli，这是“使用" 关键字。 例如：

public abstract class BaseCriticalResource : IDiposable {
    ~ BaseCriticalResource () {
        Dispose(false);
    }

    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this); // No need to call finalizer now
    }

    protected virtual void Dispose(bool disposing) { }
}

然后添加一个具有关键资源的类：

public class ComFileCritical : BaseCriticalResource {

    private IntPtr nativeResource;

    protected override Dispose(bool disposing) {
        // free native resources if there are any.
        if (nativeResource != IntPtr.Zero) {
            ComCallToFreeUnmangedPointer(nativeResource);
            nativeResource = IntPtr.Zero;
        }
    }
}
  

然后使用它就像这样简单：

using (ComFileCritical fileResource = new ComFileCritical()) {
    // Some actions on fileResource
}

// fileResource's critical resources freed at this point

另请参阅 正确实现 IDisposable。

Answer 2

我有 C++ 背景，并且使用 C# 已有大约一年的时间。 和其他许多人一样，我对为什么语言没有内置确定性资源管理感到困惑。

using 构造提供“确定性”资源管理，并内置于 C# 语言中。 请注意，“确定性”是指保证在 using 块开始执行之后的代码之前调用 Dispose。 另请注意，这不是“确定性”一词的含义，但每个人似乎都在这种情况下以这种方式滥用它，这很糟糕。

在我偏向 C++ 的大脑中，使用带有确定性析构函数的引用计数智能指针似乎是垃圾收集器的一个重大进步，垃圾收集器要求您实现 IDisposable 并调用 dispose 来清理非内存资源。

垃圾收集器不需要您实现IDisposable。 事实上，GC 完全没有注意到这一点。

诚然，我不是很聪明......所以我问这个纯粹是出于想更好地理解为什么事情是这样的愿望。

跟踪垃圾收集是模拟无限内存机器的快速可靠的方法，使程序员摆脱手动内存管理的负担。 这消除了几类错误（悬空指针、释放太快、双重释放、忘记释放）。

如果将 C# 修改为：

对象是引用计数的。 当对象的引用计数变为零时，将在该对象上确定性地调用资源清理方法，

考虑在两个线程之间共享的对象。 线程竞相将引用计数减少到零。 一个线程将赢得比赛，另一个线程将负责清理。 这是不确定的。 认为引用计数本质上是确定性的信念是一个神话。

另一个常见的误解是引用计数会在程序中尽早释放对象。 事实并非如此。 递减总是被推迟，通常推迟到范围末尾。 这使得物体的存活时间超过了必要的时间，留下了所谓的“漂浮垃圾”。 请特别注意，某些跟踪垃圾收集器可以并且确实比基于范围的引用计数实现更早地回收对象。

然后该对象被标记为垃圾回收。 垃圾收集发生在未来某个不确定的时间，此时内存将被回收。 在这种情况下，您不必实现 IDisposable 或记得调用 Dispose。

无论如何，您不必为垃圾收集对象实现 IDisposable，因此这是没有好处的。

如果有非内存资源需要释放，则只需实现资源清理功能即可。

为什么这是一个坏主意？

简单的引用计数非常慢并且会泄漏周期。 例如， Boost 的 C++ 中的shared_ptr 比 OCaml 的跟踪 GC 慢 10 倍。 即使是基于范围的简单引用计数在多线程程序（几乎所有现代程序）中也是不确定的。

这会违背垃圾收集器的目的吗？

一点也不，不。 事实上，这是一个糟糕的想法，它是在 20 世纪 60 年代发明的，并在接下来的 54 年里进行了深入的学术研究，得出的结论是引用计数在一般情况下表现不佳。

实现这样的事情可行吗？

绝对地。 早期的 .NET 和 JVM 原型使用​​了引用计数。 他们还发现它很糟糕，并放弃了它，转而使用跟踪 GC。

编辑：从到目前为止的评论来看，这是一个坏主意，因为

没有引用计数，GC 更快

是的。 请注意，您可以通过推迟计数器递增和递减来使引用计数更快，但这会牺牲您非常渴望的确定性，并且它仍然比使用当今的堆大小跟踪 GC 慢。 然而，引用计数的速度越来越快，因此在未来的某个时候，当堆变得非常大时，我们可能会开始在生产自动化内存管理解决方案中使用 RC。

处理对象图中的循环问题

试验删除是一种专门设计用于检测和收集引用计数系统中的循环的算法。 然而，它是缓慢且不确定的。

我认为第一点是有效的，但第二点很容易使用弱引用来处理。

称弱引用“容易”是希望战胜现实的胜利。 他们是一场噩梦。 它们不仅不可预测且难以构建，而且还会污染 API。

那么速度优化是否超过了您的缺点：

可能无法及时释放非内存资源

using 是否无法及时释放非内存资源？

可能会过早释放非内存资源
如果您的资源清理机制是确定性的并且内置于语言中，您就可以消除这些可能性。

using 构造是确定性的并且内置于语言中。

我认为您真正想问的问题是为什么 IDisposable 不使用引用计数。 我的回答是轶事：我使用垃圾收集语言已经有 18 年了，而且我从来不需要诉诸引用计数。 因此，我更喜欢更简单的 API，它们不会受到弱引用等附带复杂性的影响。

Answer 3

我对垃圾收集有所了解。 这是一个简短的摘要，因为完整的解释超出了这个问题的范围。

.NET 使用复制和压缩分代垃圾收集器。 这比引用计数更先进，并且具有能够直接或通过链收集引用自身的对象的好处。

引用计数不会收集循环。 与跟踪收集器相比，引用计数的吞吐量也较低（总体较慢），但具有更快的暂停（最大暂停更小）。

Answer 4

这里有很多问题。 首先，您需要区分释放托管内存和清理其他资源。 前者可能非常快，而后者可能非常慢。 在 .NET 中，两者是分开的，这样可以更快地清理托管内存。 这也意味着，只有当您有超出托管内存的内容需要清理时，您才应该实现 Dispose/Finalizer。

.NET 采用标记和清除技术，遍历堆寻找对象的根。 根实例在垃圾回收后仍然存在。 只需回收内存即可清除其他所有内容。 GC 必须时不时地压缩内存，但除此之外，即使在回收多个实例时，回收内存也是一个简单的指针操作。 将此与 C++ 中对析构函数的多次调用进行比较。

Answer 5

当用户没有显式调用 Dispose 时，实现 IDisposable 的对象还必须实现由 GC 调用的终结器 - 请参阅 IDisposable.Dispose 位于 MSDN。

IDisposable 的全部要点是 GC 在某个不确定的时间运行，而您实现 IDisposable 是因为您拥有宝贵的资源并希望在确定的时间释放它。

所以你的建议不会改变 IDisposable 方面的任何内容。

编辑：

抱歉。 没有正确阅读您的建议。 :-(

维基百科对引用计数GC的缺点有一个简单的解释

Answer 6

引用计数

使用引用计数的成本是双重的：首先，每个对象都需要特殊的引用计数字段。 通常，这意味着必须在每个对象中分配额外的存储字。 其次，每次将一个引用分配给另一个引用时，都必须调整引用计数。 这显着增加了赋值语句所花费的时间。

.NET 中的垃圾收集

C# 不使用对象的引用计数。 相反，它维护堆栈中对象引用的图表，并从根导航以覆盖所有引用的对象。 图中所有引用的对象都被压缩在堆中，以便为未来的对象提供连续的内存。 回收所有不需要最终确定的未引用对象的内存。 那些未被引用但要执行终结器的队列将被移动到一个名为 f-reachable 队列的单独队列，垃圾收集器在其中在后台调用它们的终结器。

除了上面的GC之外，还使用了代的概念来实现更高效的垃圾收集。 它基于以下概念
1. 压缩一部分托管堆的内存比压缩整个托管堆的内存要快
2. 较新的对象的生命周期较短，较旧的对象的生命周期较长
3. 较新的对象往往彼此相关并大约在同一时间被应用程序访问

托管堆分为三代：0、1 和 2。新对象存储在 gen 0 中。未回收的对象通过一个GC循环被提升到下一代。 因此，如果第 0 代中的较新对象在 GC 周期 1 中幸存下来，那么它们将被提升到第 1 代。其中那些在 GC 周期 2 中幸存下来的对象将被提升到第 2 代。因为垃圾收集器仅支持三代，所以第 2 代中的对象在集合中幸存下来的集合将保留在第 2 代中，直到确定它们在未来的集合中无法访问为止。

当第 0 代已满并且需要为新对象分配内存时，垃圾收集器将执行收集。 如果第 0 代的收集没有回收足够的内存，则垃圾收集器可以执行第 1 代的收集，然后执行第 0 代的收集。如果这没有回收足够的内存，则垃圾收集器可以执行第 2、1 和 0 代的收集因此

GC比引用计数更有效。

Answer 7

确定性非内存资源管理是该语言的一部分，但它不是通过析构函数完成的。

您的观点在具有 C++ 背景、尝试使用 RAII 设计模式的人中很常见。 在 C++ 中，即使抛出异常，也可以保证某些代码将在作用域末尾运行的唯一方法是在堆栈上分配一个对象并将清理代码放入析构函数中。

在其他语言（C#、Java、Python、Ruby、Erlang...）中，您可以使用 try-finally（或 try-catch-finally）来确保清理代码始终运行。

// Initialize some resource.
try {
    // Use the resource.
}
finally {
    // Clean-up.
    // This code will always run, whether there was an exception or not.
}

IC#，您还可以使用 using 构造：

using (Foo foo = new Foo()) {
    // Do something with foo.
}
// foo.Dispose() will be called afterwards, even if there
// was an exception.

因此，对于C++ 程序员，将“运行清理代码”和“释放内存”视为两个独立的事情可能会有所帮助。 将清理代码放在finally 块中，然后交给GC 来处理内存。

Answer 8

Brad Abrams 发布了一封来自 Brian Harry 的电子邮件在.Net框架的开发过程中。 它详细说明了未使用引用计数的许多原因，即使早期的优先事项之一是保持与使用引用计数的 VB6 的语义等效性。 它研究了一些可能性，例如对某些类型进行引用计数而不对其他类型进行引用计数（IRefCounted！），或者对特定实例进行引用计数，以及为什么这些解决方案都不被认为是可接受的。

因为【资源问题
管理和确定性
定稿]就是这样一个
我要尝试的敏感话题
尽可能精确和完整
尽我所能的解释。 我为。。。道歉
邮件的长度。 前90%
这封邮件试图说服你
这个问题确实很难。 在
最后一部分，我会谈论一些事情
我们正在努力做，但你需要
第一部分了解我们为什么
查看这些选项。

...

我们最初是从
假设解决方案将
采用自动参考的形式
计数（所以程序员不能
忘了）加上一些其他的东西
检测并处理循环
自动地。 ...我们最终得出的结论是
这在
一般情况。

...

总结：

• 我们认为解决循环问题非常重要
  而不强迫程序员
  理解、追踪和设计
  围绕这些复杂的数据结构
  问题。
• 我们希望确保我们拥有高性能（速度和性能）
  工作集）系统和我们的分析
  表明使用引用计数
  对于系统中的每个对象
  不会让我们实现这一点
  目标。
• 出于多种原因，包括构图和选角
  问题，没有简单透明的
  仅拥有这些对象的解决方案
  需要对其进行引用计数。
• 我们选择不选择提供确定性的解决方案
  最终确定为单个
  语言/语境，因为它抑制
  与其他语言的互操作
  导致类库分叉
  通过创建特定于语言的
  版本。

Answer 9

垃圾收集器不要求您为您定义的每个类/类型编写 Dispose 方法。 仅当您需要显式执行某些清理操作时才定义一个； 当您显式分配本机资源时。 大多数时候，即使您只对对象执行诸如 new() 之类的操作，GC 也只是回收内存。

GC 执行引用计数 - 但它以不同的方式执行此操作，即每次执行收集时查找哪些对象是“可访问的”(Ref Count > 0)。 ..它只是不以整数计数器的方式进行。 。 收集无法访问的对象（Ref Count = 0）。 这样，运行时就不必在每次分配或释放对象时进行内务处理/更新表......应该会更快。

C++（确定性）和 C#（非确定性）之间的唯一主要区别在于何时清理对象。 您无法预测在 C# 中收集对象的确切时刻。

第无数个插件：我建议阅读 Jeffrey Richter 在 CLR 中关于 GC 的站立章节C#，如果您真的对 GC 的工作原理感兴趣。

Answer 10

在 C# 中尝试了引用计数。 我相信，发布 Rotor（一种 CLR 的参考实现，其源代码可用）的人们进行了基于引用计数的 GC，只是为了看看它与一代的 GC 相比如何。 结果令人惊讶——“普通”GC 速度快得多，这一点都不好笑。 我不记得在哪里听到这句话了，我想那是 Hanselmuntes 的播客之一。 如果你想看到 C++ 在与 C# 的性能比较中基本上被压垮——谷歌 Raymond Chen 的中文词典应用程序。 他做了一个 C++ 版本，然后 Rico Mariani 做了一个 C# 版本。 我认为 Raymond 进行了 6 次迭代才最终击败了 C# 版本，但到那时他必须放弃 C++ 的所有面向对象的优秀特性，并深入到 win32 API 级别。 整个事情变成了性能黑客。 同时，C# 程序只优化了一次，最终看起来仍然是一个不错的 OO 项目