未初始化内存是什么？分配时为何不初始化？及相关内存问题

背景信息 #

Rust中GlobalAllocator的核心分配方法签名如下：

unsafe fn alloc(&self, layout: Layout) -> *mut u8

该方法的文档明确说明：

分配的内存块可能已初始化，也可能未初始化。

举个实际场景：如果要为[i32; 10]分配内存，已知i32大小为4字节，那么总共需要40字节的存储空间。当分配器找到符合要求的内存位置后，很多开发者会疑惑这40字节区域里的内容，常听到“垃圾数据”的说法，猜测是其他进程或程序遗留的旧数据，进而产生以下技术疑问：

问题1：未初始化内存是什么？是不是指未用零或目标类型默认值初始化的数据？ #

是的，未初始化内存就是没有被赋予任何确定值的内存区域。它既不是零，也不是目标类型的默认值，里面的内容是内存空间之前被使用后留下的随机“残留数据”——可能是当前程序之前释放的内存内容，也可能是操作系统分配给进程时自带的初始数据（不同操作系统的行为可能有差异，但都不会保证是确定值）。

从Rust的内存模型来看，读取未初始化的值属于未定义行为（UB），因为编译器无法对这类值做任何假设，可能导致程序行为异常、崩溃甚至安全问题。

问题2：为何不总是在返回指针前初始化内存？是因为成本过高吗？但为了正确使用内存、避免UB必须初始化内存，那为何返回的内存不预先初始化？ #

核心原因就是性能开销。初始化内存（比如清零）需要遍历整个内存块并写入值，对于大内存块来说，这会带来明显的时间成本。

Rust的设计哲学是“零成本抽象”，它把内存初始化的控制权交给开发者：

• 如果你的场景必须确保内存是干净的，可以使用alloc_zeroed方法（专门返回已清零的内存）；
• 如果接下来会立刻用确定值覆盖整个内存块（比如拷贝数据进去），那么预先初始化就是完全多余的操作，浪费CPU周期。

另外，Rust的unsafe代码要求开发者自行保证内存的正确使用——既然你选择使用alloc这个unsafe方法，就需要承担起初始化内存的责任，避免UB。

问题3：当资源被deallocate时，不能再指向该已释放内存。那该内存区域会被清零吗？调用deallocate释放内存时实际会发生什么？ #

调用deallocate时，内存区域不会被自动清零。释放内存的本质是告诉内存分配器：这块内存现在可以被重新分配给其他使用请求了。

具体发生的行为分两种情况：

1. 如果是用户态的内存分配器（比如Rust默认的jemalloc），它会把这块内存标记为“可用”，加入自己的空闲内存列表，后续分配请求会优先从这些空闲块中选取；
2. 如果分配器发现这块内存是操作系统直接分配的大页，可能会把它归还给操作系统，但同样不会主动清零。

正因为释放后的内存不会被清零，所以如果后续其他代码重新分配到这块内存，可能会读取到之前的残留数据——这也是为什么“使用已释放内存（野指针）”属于UB，同时也是内存安全问题的潜在来源。

内容的提问来源于stack exchange，提问作者Alex Vergara