识别 Rust 的 collect:<Vec<_>>() 内存泄漏陷阱

原文 ↗ Hacker News 讨论 ↗

Rust beta 版中 `collect::<Vec<_>>()` 的一项优化在把一个 `Vec` 转成另一个 `Vec` 时会复用分配，这可能会悄悄保留大量未使用的容量——尤其是在把较大元素类型映射成较小元素类型时——从而让内存使用量比实际活数据高出数百倍。评论者就这是否构成真正的“内存泄漏”展开争论：有人认为这只是可预期的增长与复用策略结果，也有人提到“空间泄漏”“最少惊讶原则”以及其他语言如何处理过度分配。帖子中还提出了多种补救和替代方案，包括显式调用 `shrink_to_fit`、对固定数据使用 `Box<[T]>` 或 `Box<str>`，以及在内存敏感代码中重新思考数据结构；同时，一个开放的 Rust bug 报告正在跟踪这一优化应如何调整。

这真的是“内存泄漏”吗？

  • 许多人认为这不是真正的泄漏：内存仍然由 Vec 持有，并会在被 drop 时释放；这只是过度分配。
  • 也有人指出，在托管语言文化里，这类持续的过度分配常常被口语化地称为“内存泄漏”或“空间泄漏”。
  • 几位发帖者强调，在 Rust 中，“泄漏”本来就有精确定义，因此宽泛地使用这个词会误导人，不过实际影响（RAM 耗尽）依然很严重。

新的 collect::<Vec<_>>() 优化做了什么

  • Beta 版 Rust 在通过 into_iter().collect() 转换时，会复用已有的 Vec 分配，即使元素类型发生变化也一样。
  • 这种复用没有文档说明，并且违背了许多程序员的心理模型：他们以为 collect 会构造一个全新的、大小合理的向量。
  • 其初衷是节省分配和拷贝，但现在它可能保留很大且已经过时的容量。

令人惊讶的容量膨胀（200 倍案例）

  • 例子模式：先构建一个容量很大的 Vec<T>，再通过 map/filter 变成更少数量、且元素类型小得多的 U，然后 collect::<Vec<U>>()。
  • 以前会创建一个大小合适的新分配；现在复用了旧的大缓冲区，因此每个内部 Vec 都保留了大量未使用的容量。
  • 在一个包含几十万个内部向量的 Vec<Vec<_>> 中，这会成倍放大成数 GB 的浪费内存。
  • 有人认为这完全是个 bug；也有人说，如果容量很重要，代码就应显式调用 shrink_to_fit()。

内存行为、预期与标准

  • 关于“最少惊讶原则”的争论很激烈：很多人觉得在类型/大小变化后仍复用，尤其当 cap >> len 时，太出乎意料。
  • 也有人强调，标准库只承诺返回一个集合，并不承诺具体的分配行为。
  • 更广泛的话题对比了 C++ 的 IFNDR/UB 模型与 Rust 更严格、由编译器检查的语义；Rust 往往更倾向于拒绝令人惊讶的程序，而不是默默接受它们。

真实世界中的过度分配与替代方案

  • Aho–Corasick 的一个实现里也出现过类似问题：很多小 Vec 采用翻倍增长策略后，峰值内存比 C 实现高出一倍。
  • 改用类似链表的结构（用索引连接）显著降低了内存，说明 Vec 并不总是最佳选择。

缓解措施与替代类型

  • 建议的缓解方式包括：使用 shrink_to_fit，对不可变数组使用 Box<[T]>，对字符串使用 Box<str>/Arc<str>，或者设计能避免大量可增长 Vec 的数据结构。
  • 有人建议在 collect 中加入启发式策略（例如当容量超过长度的某个倍数时自动收缩），但也有人担心这会带来隐藏开销和复杂性。