在 ruby 中运行手动 GC 是一种好习惯吗答案

【问题标题】：Is it good practice to run Manual GC in ruby在 ruby 中运行手动 GC 是一种好习惯吗
【发布时间】：2016-07-29 11:48:06
【问题描述】：

我在 Google 上读到很多关于 ruby 不会将内存释放回操作系统的信息，我也理解这一点，因为从操作系统分配内存是一个代价高昂的公平交易。

这让我问这个问题

如果开发人员希望 Ruby 将内存从 ruby 释放回操作系统，他们该怎么做。

- 我猜答案是在 Ruby 中手动触发 GC。

但是是否建议在生产应用程序上执行（运行手动 GC）。

我正在考虑在赛璐珞中创建一个单独的线程（或 Actor），以每 2 小时启动一次 GC。

任何人都可以建议。上述解决方案是否适合生产。

注意：我想我也知道 GC.start（意思是用 Ruby 停止整个世界）

注意：Ruby Version 2.2.2 MRI Centos 4G RAM with 4 core.

【问题讨论】：

【解决方案1】：

我在 Google 上读到很多关于 ruby 不会将内存释放回操作系统的信息，我也理解这一点，因为从操作系统分配内存是一个代价高昂的公平。

这根本不是真的。 Ruby 语言根本没有说明将内存释放回操作系统。事实上，Ruby 语言并没有提到内存，句号。

Ruby 有很多不同的实现，有很多不同的内存分配器和很多不同的垃圾收集器。有些将内存释放回操作系统，有些则不会，有些在托管运行时之上运行，甚至根本不管理内存。

例如，在 J9 上运行的 JRuby 会将内存释放回操作系统。使用 G1 GC、ParallelScavenge GC 或 ParallelOld GC 在 HotSpot 上运行的 JRuby 会将内存释放回操作系统。

如果开发人员希望 Ruby 将内存从 ruby 释放回操作系统，他们该怎么做。

你没有。实现将内存释放回操作系统，在这种情况下您不需要做任何事情，或者它不会将内存释放回操作系统，在这种情况下您无法做任何事情。

- 我猜答案是在 Ruby 中手动触发 GC。

如果实现不将内存释放回操作系统，则它不会将内存释放回操作系统。期间。

如果实现确实将内存释放回操作系统，那么无论您是否手动触发 GC，它都会这样做。

顺便说一句：您不能在 Ruby 中手动触发 GC。您可以建议 GC（使用GC::start），但不能触发它。

但是否建议在生产应用程序上执行（运行手动 GC）。

几乎从来没有。 GC 比您更清楚现在运行还是稍后运行是否有意义。

注意：我想我也知道 GC.start（意思是用 Ruby 停止整个世界）

不，GC::start 只是建议进行 GC。它确实不强制GC。此外，GC 并不意味着停止世界。例如。当使用 Metronome GC 在 J9 JVM 上运行 JRuby 或使用 Pauseless GC 在 Azul Zing JVM 上运行 JRuby 时，将永远停止世界。

注意：Ruby 版本 2.2.2

这不是有趣的地方。有趣的问题是您使用的是哪个实现、哪个垃圾收集器以及哪个操作系统。（当然还有所有这些的版本和配置设置。）

【讨论】：

Mittag 感谢您的回答，确切地说，操作系统是基于 unix 的 Centos。红宝石是核磁共振红宝石。我将在问题中进行编辑。
W Mittang 这就是我想要 GC.start pastebin.com/rYdYwxLJ 的原因。任何我现在都明白后果了。
在您的 pastebin 示例中，变量仍在范围内。如果您在方法中划分脚本的上半部分，则它允许可能的 GC，因为变量超出范围（无论您是否已将 nil 分配给它）。见：stackoverflow.com/questions/14107398/…

【解决方案2】：

您可能误解了您通过 Google 链接阅读的内容。内存，即 Ruby（这里和之后我的意思是 MRI 作为默认的 Ruby 实现）不会释放回操作系统（所谓的 Ruby 堆）不会释放到操作系统。时期。

您无法强制 Ruby 将 Ruby Heaps 释放回操作系统（除了冷重启整个应用程序。）

可能释放回操作系统的内容由 Ruby 内部发布，无论如何都是一种不好的做法，手动调用 GC 在 99% 的情况下会降低应用程序的速度，在剩下的 1% 则完全没有效果。

【讨论】：