一位同事仅通过升级MRI修复了他的记忆泄漏，请参阅this blog post
我们暂时转向Rubinius，原因之一是因为我们认为它有优越的垃圾收集。
看来Rubinius没有垃圾收集符号，请参阅此issue。这仍然是这种情况，GC-ing符号是一个很大的改进吗？
我在rubinius中读过concurrent GC，这似乎解决了与MRI增量GC相同的问题，即消除了长GC暂停时间。我也在rubinius中看过this description of generational GC。但是，我不知道如何根据RBX GC确定MRI GC的大小。
那么有谁知道哪个更好？
答案 0 :(得分：3)
看来Rubinius没有垃圾收集符号，看到这个问题。这仍然是这种情况，GC-ing符号是一个很大的改进吗？
Rubinius目前没有垃圾收集符号。我们最终会对此进行补充，但目前还有更紧迫的事情需要处理（例如支持LLVM 3.6 / MCJIT）。
符号GC是否会改善取决于您的应用程序。如果所说的应用程序正在创建许多很少使用的符号，那么可以节省一些内存。解决这个问题的最佳方法是在切换到收集符号的GC之前/之后测量内存使用情况。
那么有谁知道哪个更好？
Rubinius的＆＃39; GC旨在减少和缩短暂停时间（它不是100％并发意味着它 仍然暂时暂停所有内容）并且旨在精确（意味着它确切地知道要收集什么）而不是丢失对象）。这是否会导致更好的垃圾回收取决于您正在运行的应用程序类型。