Rust 中“内存安全”是否意味着一定不会发生内存泄漏？

知识点图片

简单直接的回答：不意味着。

在 Rust 中，“内存安全”（Memory Safety）并不保证一定不会发生“内存泄漏”（Memory Leak）。

虽然 Rust 的所有权（Ownership）和借用（Borrowing）机制能自动避免绝大多数的内存泄漏，但在 Rust 的定义中，内存泄漏并不属于“内存不安全”的范畴。

以下是详细的解释：

1. 什么是 Rust 定义的“内存安全”？

Rust 所承诺的“内存安全”，主要是为了防止未定义行为（Undefined Behavior, UB）。具体的“不安全”情况包括：

空指针解引用（Null Pointer Dereferencing）。
悬垂指针 / 野指针（Dangling Pointers / Use-After-Free）：访问已经被释放的内存。
双重释放（Double Free）：对同一块内存释放两次。
数据竞争（Data Races）：多线程环境下不安全地访问同一块内存。
缓冲区溢出（Buffer Overflow）：访问超出了数组或切片的边界。

如果发生上述情况，程序可能会崩溃、产生错误的数据或被黑客利用。Rust 保证在 Safe Rust（非 unsafe 代码块）中，这些情况永远不会发生。

2. 为什么“内存泄漏”被认为是“安全”的？

内存泄漏是指程序分配了内存，但在不再需要时没有释放它。

虽然内存泄漏会导致程序占用越来越多的 RAM，甚至导致系统因内存耗尽（OOM）而杀掉进程，但从计算机科学的底层定义来看：

泄漏的内存依然是合法的内存。
程序并没有访问“不该访问”的地方。
程序没有破坏数据的完整性。

因此，Rust 官方认为内存泄漏虽然是逻辑 Bug，但它不是内存安全漏洞。事实上，Rust 标准库中甚至提供了一个安全函数 std::mem::forget，它的作用就是显式地泄漏内存（即获取所有权但不运行析构函数）。

3. 在 Safe Rust 中如何发生内存泄漏？

即使不写 unsafe 代码，Rust 中也有几种常见的方式会导致内存泄漏：

A. 引用循环（Reference Cycles）

这是 Rust 中最常见的泄漏方式。如果你使用引用计数智能指针（如 Rc<T> 或 Arc<T>）并结合内部可变性（如 RefCell<T>），就有可能创建循环引用。

例子：
对象 A 持有对象 B 的 Rc 指针，对象 B 也持有对象 A 的 Rc 指针。

当外部作用域结束时，A 和 B 的引用计数都减 1。
但是因为它们互相指着对方，引用计数永远不会变成 0。
因此，它们的 drop 方法永远不会被调用，内存也就永远不会被释放。

B. `std::mem::forget`

你可以显式调用这个函数来告诉编译器：“忘了这个变量吧，不要调用它的析构函数（Drop trait）”。这在 FFI（外部函数接口）编程中很有用（比如把内存管理权移交给 C 语言代码），但如果用错了就会导致泄漏。

C. 静态集合只进不出

如果你有一个全局的 static 集合（例如用 Mutex 包装的 Vec），并且不断往里面 push 数据却从不删除，这在任何语言中都是一种逻辑上的内存泄漏。

4. Rust 如何缓解内存泄漏？

虽然 Rust 允许内存泄漏，但它的设计让泄漏变得很难发生（除了引用循环这种特例）：

RAII（资源获取即初始化）： 绝大多数情况下，依靠所有权系统，一旦变量离开作用域，Rust 会自动调用 drop 释放内存。这解决了 99% 的手动管理内存导致的泄漏问题。
弱引用（Weak Pointers）： 针对 Rc 和 Arc 的循环引用问题，Rust 提供了 Weak<T>。Weak 指针不增加强引用计数，因此可以用来打破循环引用（例如：父节点持有子节点的 Rc，子节点持有父节点的 Weak）。

总结

内存安全 = 不会出现段错误、数据竞争、野指针等导致程序崩溃或数据损坏的行为。
内存泄漏 = 内存没被释放，但这在 Rust 看来是“安全”的操作（虽然通常是不想要的结果）。

所以，写 Rust 代码时，你依然需要注意引用循环等逻辑问题，以防止内存泄漏。

播面