Ruby运行时能否自动合并相同内容的冻结对象为单实例？

为什么冻结字符串不会自动合并同内容实例 #

你的测试结果完全符合Ruby的实际运行逻辑，最初的猜想不成立的核心原因有两点：

• freeze方法的作用仅为标记对象不可修改，本身不携带任何自动合并同内容对象的逻辑。示例代码中每次执行'foo'.dup都会在堆上创建一个全新的字符串实例，后续调用freeze只是锁死这个新实例的可修改属性，不会将它和其他同内容的冻结字符串做归并。
• 运行时自动合并冻结字符串会直接破坏程序稳定性：Ruby的对象引用是直接指向内存地址的，如果后台线程偷偷把多个不同object_id的冻结对象合并为单个实例，所有指向原对象的引用都会变成悬空指针，引发不可预期的错误，因此Ruby从设计上就不会做这类运行时后台扫描合并。

这里需要区分一个常见认知误区：开启frozen_string_literal魔法注释后同内容字面量字符串会指向同一个实例，这是编译期优化行为——Ruby在解析代码时就能确定所有字面量字符串的引用位置，可以安全做归并；但dup、IO读取、字符串拼接等运行时动态生成的字符串，完全享受不到这个编译期优化，不管等多久都不会自动合并。

你的测试代码返回1000是完全正常的结果：

a = Array.new(1000) { 'foo'.dup.freeze } # create separate objects, but freeze them
sleep 5 # give the runtime some time to combine the objects
a.map(&:object_id).uniq.size # => 1000

可用的内存优化方案 #

你考虑的转Symbol方案仅在特定场景下可用：如果你的唯一字符串量级极小、且全部为代码中静态定义的内容，不会动态生成未知内容的字符串，这个方案确实能实现去重降内存的效果。但要注意Symbol一旦创建永远不会被垃圾回收，如果字符串来自用户输入、外部文件读取等动态来源，存在被构造大量唯一值撑爆内存的风险，不推荐优先使用。

更通用、安全的优化方案有以下两种：

• 使用内置的字符串去重方法String#-@：这是Ruby 2.5版本后官方推荐的去重方案，调用-str时，Ruby会检查全局共享字符串池中是否存在内容相同的冻结字符串：如果存在直接返回池中的实例，不存在则将当前字符串冻结后放入池中再返回。池中的字符串在所有引用消失后可以被正常垃圾回收，没有Symbol永久驻留的内存泄漏风险。
  改写你的测试代码即可得到预期的结果：

  a = Array.new(1000) { -'foo'.dup }
  a.map(&:object_id).uniq.size # => 1
  

  这个方案的内存占用和Symbol基本一致，同时兼容动态生成的字符串场景，适用范围最广。
• 自定义字符串缓存池：如果需要处理批量临时的重复字符串，可以自己用Hash维护一个缓存池，例如str_pool = Hash.new { |h, k| h[k] = k.freeze }，所有要存储的字符串都先通过str_pool[str]获取去重后的冻结实例。这个方案的优势是缓存生命周期完全可控，这批字符串处理完成后直接清空缓存池，所有字符串实例就可以被正常GC，适合临时批量数据处理的场景。

注意：Ruby不存在任何运行时自动合并重复对象的机制，所有字符串去重都需要在创建字符串的环节主动触发，不要依赖后台自动优化的行为。

内容的提问来源于stack exchange，提问作者Keith Bennett