Ruby 的 Hash 用起来省心但内存回收不一定按你预期的路径走。这次我们来看一个非常常见、又容易被忽视的问题一个大 Hash 删掉了大部分键进程 RSS 却几乎不下降。如果这个 Hash 是长驻服务里的全局缓存、会话表或者批量任务里的中间结果多占的内存就会一直挂在进程上直到进程重启。这类问题的核心是 Hash 底层那张桶表bucket table的容量“只增不减”。删除键只是把槽位清空底层的存储结构并不会立刻缩小。只要你还持有这个大 Hash那份大容量表就会继续占用内存。本文会用一段可复现的 Ruby 脚本演示这个问题然后给出几种收缩 Hash 的方案包括重建 Hash、select、rehash以及批量任务里的内存观测思路。这次内容不需要 GPU、不需要安装模型只需要一个 Ruby 环境。适合写 Ruby 服务、做数据处理脚本或者对 CRuby 内存行为好奇的读者。你可以直接复制脚本到本机跑一遍观察自己的 Ruby 版本在“大 Hash 删除键之后”到底会不会释放内存。1. 核心问题与方案速览项目说明核心问题Ruby Hash 底层桶表容量只增不减删除大量键后内存不能及时释放关键技术点Hash 内部桶表、load factor、重建 Hash、select、rehash验证工具ObjectSpace.memsize_of、GC.start、进程 RSS适用版本Ruby 2.x / 3.x不同版本内部实现有差异以本机实测为准适用场景长驻服务中的缓存、大数据量 Hash、批量数据处理、内存受限环境使用边界小 Hash 重建开销可能大于收益应该先测量再优化最直接的收缩方式遍历原 Hash构造一个新的 Hash 并替换原引用这里有一个需要强调的认知Hash#size返回的是键值对数量不是 Hash 占用的底层内存。一个删到只剩 10 万条数据的 Hash底层桶表可能还是按 100 万条数据扩容后的规格。这是因为 Hash 在做插入时会在负载因子达到阈值后把桶数组扩大一倍而删除操作往往不会触发等比例的收缩。2. 适用场景与使用边界先说什么时候应该关注 Hash 收缩。第一类场景是长驻服务。Web 服务、API 网关、消息处理程序启动后常驻内存如果把大量数据装进 Hash 做缓存或去重之后又删掉大部分键内存不会因为你删了键就立刻归还给操作系统。时间一长进程占用持续偏高GC 压力也跟着上来。第二类场景是批量数据处理脚本。比如一次导入几百万行数据先分组放进 Hash再逐步消费。中间如果保留了大量“已经用不上的空桶”脚本峰值内存会明显高于数据量本身。这类脚本跑在容器或 CI 环境里时内存上限很敏感能省一点是一点。第三类场景是内存受限环境。云函数、Sidecar、嵌入式环境里Ruby 进程的内存配额固定Hash 底层表不收缩会让本来够用的配额变得紧张。再说边界。小 Hash 不需要折腾。一个只有几百条键值对的 Hash底层桶表也就几千字节重建一个新 Hash 反而多一次遍历和分配。对性能敏感的服务这种开销是纯浪费。不要为了省内存牺牲可读性。如果业务代码里到处是hash.each_with_object({}) { ... }会让维护者困惑。更合适的做法是把“收缩 Hash”封装成一个方法或者直接用它来替代“删除后的残留大 Hash”这种极端情况。先测量再优化。不要凭感觉说“我的 Hash 占了很多内存”。先用 ObjectSpace 和 RSS 把数字测出来确认问题存在再动手改代码。3. 环境准备与验证方法这部分只需要一个可运行的 Ruby 环境。建议用 Ruby 3.x 做验证因为新版 GC 和 Hash 实现相对更成熟但这篇文章给出的思路在 Ruby 2.6 以上基本通用。先确认 Ruby 版本ruby -v然后创建一个工作目录用来放测试脚本mkdir -p ruby-hash-shrink cd ruby-hash-shrink在 Linux 环境里可以通过/proc/self/status读取当前进程的 VmRSS用来观察脚本自身的内存占用。macOS 没有这个文件可以用ps -o rss -p $$代替。Windows 则可以用任务管理器或 WMI 观察不过接下来的示例脚本以 Linux 为主。写脚本前先说明一个观察工具ObjectSpace.memsize_of。它返回某个对象在 GC 眼中的内存大小对 Hash 来说能给出一个参考值但不是绝对精确的进程内存统计。实际判断内存释放还是要看 RSS 变化。4. 先复现问题删除大量键之后内存不下降我们先构造一个 100 万条数据的 Hash再删掉其中的 90 万条观察删除前后 RSS 和对象内存大小。require objspace def rss_kb File.read(/proc/self/status)[/VmRSS:\s(\d)/, 1].to_i end hash {} 1_000_000.times do |i| hash[i] value_#{i} end GC.start puts inserted: size#{hash.size} rss#{rss_kb}KB obj#{ObjectSpace.memsize_of(hash)}B hash.delete_if { |k, _| k 900_000 } GC.start puts deleted : size#{hash.size} rss#{rss_kb}KB obj#{ObjectSpace.memsize_of(hash)}B运行方式ruby memory_check.rb在多数 CRuby 版本里你会看到类似下面的现象size从 1000000 降到 100000rss可能只有轻微下降ObjectSpace.memsize_of(hash)仍然是一个比较大的数值。原因在于delete_if是原地修改它清空了 90 万个键值对但 Hash 内部那张桶表还保留着按 100 万条数据扩容后的容量。桶表里的空槽位只是标记为“已删除”并没有归还给内存分配器。这里有一个容易混淆的点如果删除键后你不再持有这个大 HashRuby GC 会回收整张表内存自然会降下来。但问题恰恰是业务代码往往还需要保留剩下的那一小部分数据。于是一个只装 10 万条数据的 Hash带着 100 万条数据的桶表继续活着。判断是否复现成功可以看两点size明显变小rss或ObjectSpace.memsize_of(hash)没有按比例下降。如果你的 Ruby 版本在删除后自动收缩了桶表那说明当前版本的实现已经优化得比较好下面的收缩方案可以根据实际情况选用。5. 收缩 Hash 的几种方法5.1 遍历重建最直接可靠既然旧 Hash 的桶表太大最简单的思路就是创建一个新 Hash把剩余键值对依次放进去。def shrink_hash(original) result {} original.each { |k, v| result[k] v } result end hash shrink_hash(hash) GC.start puts shrunk : size#{hash.size} rss#{rss_kb}KB obj#{ObjectSpace.memsize_of(hash)}B新 Hash 在插入过程中会按照实际条目数重新分配桶表通常不会再按照旧表的规模扩容。旧 Hash 在失去引用后变成垃圾对象下一次 GC 就会回收它的底层大表。这个方法有几个优点逻辑简单不依赖某个 Ruby 版本内部细节不改变键值对内容可以顺便打断原有的超大桶结构。缺点是会多一次遍历和分配所以只适合“数据量大、需要长期持有”的场景。5.2 用 select 替代 delete_if很多时候我们不是想“删掉键”而是想“保留满足条件的数据”。这时直接使用select会返回一个新 Hash从写法上就避开了原地删除的问题。hash hash.select { |k, _| k 900_000 }这行代码等价于“新建一个 Hash把符合条件的键值对放进去”。比起delete_if它更符合“我要一个小 Hash”的语义也更容易让代码评审的人看出意图。如果是既要修改原 Hash又要释放内存可以先select出小 Hash再把原变量指向新对象。注意如果原 Hash 还被其他变量引用那个引用仍然会保持大桶表所以要把所有引用都清理干净。5.3 rehash 不是收缩内存的万能药Hash#rehash的作用是根据键当前的hash和eql?结果重建内部索引。它最典型的用途是键对象在放入 Hash 后被修改了导致原来的哈希值失效。key [1] h { key :hello } key 2 # 此时通过 h 查找原始 key 可能失败 h.rehash puts h[key] # :hello从内部实现看rehash会重新整理底层表结构但它主要解决的是“键的哈希值已变化”的正确性问题不能保证把容量收缩到与当前条目数匹配。如果你的目标是压缩内存还是优先用遍历重建。5.4 Hash[] 复制是否可行Hash[original]也会生成一个新 Hash 对象。新对象在构造时会按新条目数分配桶表吗这在不同的 Ruby 版本里行为不完全一致。有的版本会沿用原实现的一些容量信息有的版本会重新分配。从稳妥角度考虑不建议把它当作标准收缩方案。需要可预测行为时用 5.1 的遍历重建最保险。6. 键类型与值对象的选择收缩 Hash 解决的是“已有 Hash 太大”的问题。更进一步的优化是在源头减少 Hash 的膨胀。键类型影响很大。一段反复执行的代码如果每次都用字符串字面量当键比如hash[user_1] 1每次都会创建一个新的字符串对象。改成 Symbol 作为固定业务键可以减少大量临时对象HASH_KEY :user_1当然动态数据不太适合转 Symbol因为 Symbol 本身也会占用内存。判断标准很简单键的集合是不是固定的。固定的用 Symbol动态的用 String 反而更合适。值对象也要注意。如果 Hash 里存放的是大量只读字符串考虑freeze或复用同一个对象。字符串在没有冻结时即使内容相同也是一个个独立对象。冻结后可以在一定程度上共享从而减少重复分配。极端情况下换数据结构。当你需要保存几百万条扁平记录每条记录都是一个 5 字段 Hash 时Hash 本身的开销会非常大。这时可以把字段改成定长数组或 Struct内存下降往往比收缩 Hash 更明显。Record Struct.new(:id, :name, :status) records [] records Record.new(1, alice, :active)Struct 的对象开销比 Hash 小适合字段固定、数量巨大的场景。如果还需要快速按 id 查找可以只在外层维护一个 “id - index” 的 Hash把数据本体放进数组。7. 批量任务与内存观测在实际项目中最常见的情况是脚本从文件或数据库读入大量数据放进 Hash 做处理处理完一批再读下一批。如果整个流程只有一张大 Hash内存在高峰时就会很难看。一个通用的思路是按批次处理每批做完后主动清理引用再继续下一批。def process_in_batches(enum, batch_size: 10_000) batch [] enum.each do |item| batch item if batch.size batch_size yield batch batch [] end end yield batch unless batch.empty? end users (1..1_000_000).lazy.map { |i| { id: i, name: user_#{i} } } process_in_batches(users, batch_size: 20_000) do |batch| # 处理当前批次不要把 batch 缓存到外层 Hash puts batch size#{batch.size} end这里的要点是“不要让中间结果粘连在一个全局 Hash 上”。如果每批数据都要汇总可以把汇总值放在一个只存计数的小 Hash 里而不是把所有原始对象都堆进去。批量任务的内存观测也很重要建议在脚本里打印关键节点的 RSSGC.start rss File.read(/proc/self/status)[/VmRSS:\s(\d)/, 1].to_i puts after batch #{batch_index}: rss#{rss}KB如果 RSS 持续上涨优先怀疑三个地方某个 Hash 还在接收新数据旧数据没有被清理所有批次结果都累积在数组或 Hash 里删除键后只改了size底层桶表没收缩。写批量任务之前先在内存里确定“哪些对象是要跨批保留的”。只保留聚合结果和必要的索引不要让原始数据一直留在堆里。8. 常见问题与排查方法问题现象可能原因排查方式解决方案删除大量键后 RSS 不下降底层桶表未收缩旧 Hash 仍被持有观察 size 与 RSS 变化检查全局变量引用遍历重建 Hash释放所有引用重建后内存反而升高旧 Hash 还没有被 GC在重建后调用 GC.start 再测确认旧 Hash 无引用等待 GCselect 之后原 Hash 还被占用其他变量仍持有原 Hash 引用搜索变量引用关系将旧引用置为 nilrehash 后数据查找异常键对象的 hash/eql? 行为不稳定检查自定义键类的 hash 方法避免使用可变对象做键Hash 内存降低但 CPU 上升频繁重建大 Hash 导致 CPU 开销用 benchmark 对比重建频率低频重建换数据结构批量任务 RSS 持续上涨中间结果累积在 Hash/数组每批打印 RSS定位增长点分批处理清理引用这里把几个关键点拆开说明。为什么删了键 RSS 还不降因为删除和内存归还不是同一件事。Hash 底层表保留了大量空槽这些空槽属于 Hash 对象本身。除非 Hash 被回收或者桶表被重新分配否则内存不会释放。为什么重建后内存反而更高重建时旧 Hash 和新 Hash 会同时存在一瞬间。如果旧 Hash 还有 10 万条数据两者叠加峰值内存会短暂上升。解决办法是重建完成后立刻把旧引用清掉并调用一次 GC。rehash 和收缩的区别。rehash解决键哈希值变化后的正确性问题收缩解决容量过大的内存问题。两者不是一个东西不要混用。自定义键类要格外小心。如果一个类重写了hash方法但返回值不稳定放进 Hash 后又会变化rehash也无法保证所有键都能找回来。更安全的做法是避免用会变化的对象做键。9. 最佳实践与使用建议综合前面的分析下面是一套比较实用的工程化建议。第一先建立内存基线。在一个脚本里测量 Hash 插入、删除、重建三个阶段的 size、RSS、ObjectSpace 数值。只有拿到基线才能判断“需不需要优化”“优化后有没有效果”。第二删除大 Hash 后优先重建。如果需要长期保留剩余数据建议用each遍历重建而不是delete_if。如果只是取子集用select拿到新 Hash 更自然。第三固定键集合用 Symbol。这个优化虽然小但在大量小 Hash 组成的数组里效果明显。注意不要为了追求 Symbol 而给动态数据硬转 Symbol那会制造出不可控的 Symbol 池。第四批量任务按批次处理。不要让所有数据同时堆积在 Hash 或数组里设置批次大小每批处理完就把局部变量释放。配合 GC.start 观察能比较清楚地看到内存涨落。第五对 Hash 生命周期做好规划。一个 Hash 如果注定只会被短期使用就不要把它长期挂在全局变量里。到期请主动设成nil让 GC 有机会回收。第六不要过度优化。如果 Hash 只有几百条数据或者删除频率很低重建的额外 CPU 开销不值得。先让代码保持可读遇到真实内存问题时再做收缩。第七替换后跑一遍完整测试。收缩 Hash 不会改变键值对内容但如果你的 Hash 存储了带重复键的对象或者依赖default_proc重建后要确认行为一致。def rebuild_with_default(original, default_proc) result Hash.new(default_proc) original.each { |k, v| result[k] v } result end10. 总结这次围绕 “Shrinking Ruby Hashes” 展开的核心结论就一句话Ruby Hash 的 size 变小不代表底层内存变小想要真正释放内存最可靠的做法是遍历重建 Hash或者用 select 生成新 Hash。值得做的三件事先写一个脚本测量自己 Ruby 版本下“删除键后内存是否下降”在长驻服务或批量任务里把大 Hash 的删除改成重建把 RSS 和 ObjectSpace 的观测加入日常开发调试流程。最容易踩的坑是以为delete_if之后内存会自动回来。实际上底层桶表可能还是原来那么大。另一个坑是rehash被误当成内存收缩工具使用它真正解决的是键哈希值变化后的索引重建。后续可以继续探索的方向包括用 Struct 代替大批量小 Hash、用compare_by_identity降低某些场景的哈希计算成本、以及在 Ruby 3.x 上对比不同 GC 配置下的内存表现。建议先跑完上面的脚本把你当前版本的行为摸清楚再做后续优化。