Ruby栏目

Ruby的内存陷阱

Ruby有一套自动的内存管理机制。这在大多数情况下是不错的，但是有时它却是个麻烦。

Ruby的内存管理既简洁又笨重。它将对象（名为 RVALUE）存储在大约有16KB大小的堆中。
从底层上，RVALUE 是一个 C 的结构体，它包含了一个共同体表示不同的标准ruby对象。

因此在堆中存储着大小不超过40字节的 RVALUE 对象，如 String、Array、Hash等。
这意味着小的对象在堆中很合适，但是一旦它们达到到阈值，那么就需要在Ruby的堆之外再分配一片额外的内存。

这块额外的内存空间是灵活的。一旦对象被垃圾回收了它就会被释放掉。但是堆本身的内存是不会被释放给操作系统的。

让我们来看一个简单的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
def report
  puts 'Memory ' + `ps ax -o pid,rss | grep -E "^[[:space:]]*#{$$}"`
          .strip.split.map(&:to_i)[1].to_s + 'KB'
end

report
big_var = " " * 10_000_000
report
big_var = nil
report
ObjectSpace.garbage_collect
sleep 1
report

# ⇒ Memory 11788KB
# ⇒ Memory 65188KB
# ⇒ Memory 65188KB
# ⇒ Memory 11788KB

这里我们分配了大量的内存，使用完后又释放给操作系统。这一切看起来似乎没有问题。现在让我们稍微修改一下代码：

1
2
-  big_var = " " * 10_000_000
+  big_var = 1_000_000.times.map(&:to_s)

这只是一个简单的修改，不是吗。但是结果：

1
2
3
4
# ⇒ Memory 11788KB
# ⇒ Memory 65188KB
# ⇒ Memory 65188KB
# ⇒ Memory 57448KB

怎么回事？内存没有释放归还给操作系统。这是因为数组中的每个元素符合 RVALUE 的大小并存储在ruby的堆中。

在大多情况下这是正常的。现在ruby堆中多了许多空的位置，再次运行代码将不会再消耗额外的内存了。
每次我们处理 big_var 和一些空的堆时， GC[:heap_used]的值果然减小了。
对于这些操作Ruby是早有准备，注意这里是Ruby而不是操作系统。

因此，对于创建大量的符合40个字节的临时变量就要注意了：

1
2
big_var = " " * 10_000_000
big_var.gsub(/\s/) { |c| '-' }

结果同样是Ruby的内存疯狂增长，并且这部分内存在程序运行期间是不会归还给操作系统的：

1
2
3
4
# ⇒ Memory 10156KB
# ⇒ Memory 13788KB
# ⇒ Memory 13788KB
# ⇒ Memory 12808KB

这个问题不是太重要，稍微注意一下即可。

原文地址：http://rocket-science.ru/hacking/2013/12/17/ruby-memory-pitfalls/