自 2.1 以来，MRI 2.2 对 GC 进行了一些重大改进，即增量 GC，现在它可以垃圾收集符号。
一位同事通过升级 MRI 解决了他的内存泄漏问题，请参阅这篇博文
我们不久前切换到 Rubinius，其中一个原因是因为我们认为它具有出色的垃圾收集能力。
似乎 Rubinius 不会垃圾收集符号，请参阅这个问题。情况仍然如此吗？ GC-ing 符号是一个很大的改进吗？
我在 rubinius 中阅读过并发 GC，它似乎解决了与 MRI 的增量 GC 相同的问题，即消除了较长的 GC 暂停时间。我也在rubinius 中看到了对分代 GC 的描述。但是，我不知道如何根据 RBX GC 确定 MRI GC 的大小。
那么有谁知道哪个更优呢？
似乎 Rubinius 不会垃圾收集符号，请参阅此问题。情况仍然如此吗？ GC-ing 符号是一个很大的改进吗？
Rubinius 目前不垃圾收集符号。我们最终会添加它，但现在有更紧迫的问题需要处理（例如，对 LLVM 3.6/MCJIT 的支持）。
被 GC 处理的 Symbols 是否会有所改进取决于您的应用程序。如果所述应用程序正在创建大量很少使用的符号，那么可以肯定，它可以为您节省一些内存。解决这个问题的最好方法是在切换到收集符号的 GC 之前/之后测量内存使用情况。
那么有谁知道哪个更优呢？
Rubinius 的 GC 旨在减少和缩短暂停（它不是 100% 并发，这意味着它仍然会偶尔暂停所有内容）并且旨在精确（意味着它确切地知道要收集什么而不是丢失对象）。这是否会再次导致出色的垃圾回收取决于您正在运行的应用程序的类型。