Rust 服务未泄漏——问题可能出在分配器上
本文探讨了 Rust 服务中常见的内存泄漏误判问题。作者指出，当 Rust 服务的内存占用持续增长时，开发者往往首先怀疑代码泄漏，但真正原因可能在于内存分配器（allocator）的行为差异。文章通过具体案例分析了不同分配器（如 jemalloc、glibc malloc 等）在内存管理策略上的区别，以及它们如何影响进程的实际内存占用。理解这些机制有助于开发者更准确地诊断性能问题，避免在不必要的地方浪费调试时间。
背景速读
- Rust 默认使用系统分配器（如 glibc ptmalloc），在高并发或长时间运行的服务中，内存碎片化和元数据开销会导致 RSS（常驻内存）持续增长，容易被误判为"内存泄漏"。
- 该文作者在实践中发现，将默认分配器替换为 **jemalloc**（Facebook 广泛使用的分配器）或 **mimalloc**（Microsoft 开源的高性能分配器）后，RSS 明显下降且更稳定。
- 关键区别：系统分配器偏向通用场景，而 jemalloc/mimalloc 针对多线程和碎片整理做了专门优化，代价是略有额外 CPU 开销或更激进的内存回收策略。
- 这不是 Rust 语言本身的 bug，而是*分配器选择*问题。类似问题在 Go、Python、Java 等其他管理内存的语言中也会出现，只是监控指标不同（常被误认为是 heap 增长）。
- 诊断方法：用 `jemalloc` 的统计接口或 `/proc/[pid]/smaps` 查看匿名大页和碎片情况，而非只看 `top` 或 RSS 总量。