在Rust 1.36之前，开发者依赖于std::mem::uninitialized来为稍后初始化的值分配堆栈内存。这个函数在本质上是不安全的，因为它告诉编译器在该内存位置存在有效的T，尽管位是随机的。对于具有安全不变式的类型，例如bool、char或引用，这会导致立即的未定义行为，因为编译器会根据假设值是有效的进行优化（例如一个bool是0或1）。RFC 1892引入了MaybeUninit<T>作为一种类似联合体的抽象，明确表示内存尚未包含有效的T，解决了这一安全漏洞。
核心问题源于LLVM对未初始化内存的处理，将其视为undef或poison，以及Rust的自动析构函数生成。当编译器认为某个类型为T的变量是活动的时，它可能会发出析构函数调用或细分优化。如果T是bool，未初始化的字节可能会持有值2，这违反了位有效性不变式。在析构检查或鉴别符检查期间读取它会构成未定义行为。此外，如果初始化在数组的某个部分失败，数组类型的析构胶水将试图丢弃所有元素，将未初始化的堆栈字节解释为指针，导致使用后释放或双重释放错误。
MaybeUninit<T>充当一个类型容器，可能持有有效的T，也可能不持有。它防止编译器假设初始化，从而抑制析构胶水的发出和无效位模式的优化。程序员必须手动跟踪哪些实例已初始化，通常通过单独的索引或布尔数组。要提取一个值，可以使用assume_init、assume_init_ref或std::ptr::read，但只能在通过write或指针操作证明性地写入有效的T之后。关键的不变式是assume_init绝不能在未完全初始化的内存上调用，当放弃一个部分初始化的结构时，程序员必须使用ptr::drop_in_place手动丢弃仅已初始化的元素，以避免资源泄漏。
use std::mem::{self, MaybeUninit}; use std::ptr; fn init_array_fallible<T, E, const N: usize>( mut f: impl FnMut(usize) -> Result<T, E>, ) -> Result<[T; N], E> { let mut array: [MaybeUninit<T>; N] = unsafe { MaybeUninit::uninit().assume_init() }; let mut i = 0; while i < N { match f(i) { Ok(val) => { array[i].write(val); i += 1; } Err(e) => { for j in 0..i { unsafe { ptr::drop_in_place(array[j].as_mut_ptr()); } } return Err(e); } } } Ok(unsafe { mem::transmute::<[MaybeUninit<T>; N], [T; N]>(array) }) }
您正在为一个禁止堆分配且必须具有确定性延迟的网络接口卡开发一个no_std内核驱动程序。您需要在堆栈上分配一个固定大小的1024个Connection对象的表。每个Connection的初始化涉及一个硬件寄存器写入，如果NIC缓冲区满则可能失败。问题是确保在第500个连接失败时，前499个连接被正确关闭（丢弃文件描述符和释放DMA映射），同时将剩余的524个槽保持不变，避免因丢弃未初始化内存而导致的未定义行为。
一种潜在的方法是利用Default::default()预初始化数组为哨兵值。这要求Connection实现Default，这是有问题的，因为“默认”连接仍然会获取必须显式释放的内核资源，复杂化了错误路径。此外，创建1024个虚拟连接仅仅为了覆盖它们浪费了初始化周期，并违反了驱动程序在上线过程中的严格时间要求。
第二种策略是使用Vec<Connection>与with_capacity和动态推送，然后转换为固定数组。这在用户空间代码中是安全且惯用的。然而，Vec要求全局分配器，而在这个内核上下文中没有可用。同时，它还引入了潜在的恐慌路径和内存碎片，这是内核空间不可接受的，并且转换为固定大小数组还需要运行时检查，这使得错误处理逻辑变得复杂。
第三种方法利用MaybeUninit<[Connection; 1024]>在不初始化的情况下分配存储。一旦成功初始化连接，则通过MaybeUninit::write写入，如果在索引i发生错误，我们手动遍历从0到i-1并在每个已初始化的槽上调用ptr::drop_in_place，然后返回错误。成功时，我们将整个数组转换为已初始化类型。我们选择这个解决方案是因为它提供零成本的堆栈分配和确定性性能，满足no_std约束，并确保资源清理仅在真正已初始化的对象上进行。结果是一个健壮的驱动程序，在部分失败恢复过程中从未调用未定义行为，并保持了一致的微秒级初始化延迟。
为什么在未初始化的MaybeUninit<T>上调用assume_init即使该值之后从未显式读取也构成未定义行为？
许多候选人认为，未定义行为仅在物理访问数据时才会发生，例如打印它或根据它进行分支。然而，Rust的类型系统会立即通知编译器在调用assume_init时存在有效的T。对于具有细分优化的类型（如bool、char、Option<&T>或NonNull<T>），编译器可能会生成代码以检查位模式以确定枚举变体或有效性。如果内存持有随机位（例如，bool的0xFF），这种检查会触发LLVM中的未定义行为（加载poison或undef）。此外，当作用域结束时，编译器会为T插入析构胶水，这将尝试对垃圾数据运行析构函数，导致崩溃或安全漏洞。因此，assume_init是程序员保证有效初始化的合同；违反它会污染编译器的状态，而不管显式读取。
使用MaybeUninit::write与std::ptr::write的返回的指针通过MaybeUninit::as_mut_ptr()时，二者有什么区别，何时各自适用？
MaybeUninit::write是一个安全的方法，它获得一个T的所有权并将其写入未初始化的位置，返回对现在已初始化数据的可变引用。当您准备好值并想要立即安全访问时，比较推荐这种方法。相反，std::ptr::write是一个不安全函数，向原始指针写入值，而不读取或丢弃旧值（这在内存未初始化时至关重要）。当您通过从as_mut_ptr()获得的原始指针写入时，必须使用ptr::write，并且需要避免write的借用检查限制，或者在实现仅有原始指针的低级抽象时。关键区别在于，write提供安全保证和生命周期跟踪，而ptr::write需要手动验证目标有效、对齐并未初始化，以避免别名违规或过早丢弃。
如何正确丢弃部分初始化的MaybeUninit<T>数组而不泄漏资源或引发未定义行为，操作顺序为何至关重要？
当初始化在索引i处失败时，您必须仅丢弃元素0..i。正确的程序是从0迭代到i-1并调用std::ptr::drop_in_place(array[j].as_mut_ptr())。这将为T运行析构函数，而不将值移出MaybeUninit包装器（这会将槽留在一个移动后的状态，尽管仍被视为未初始化）。立即在失败时进行此清理至关重要，在返回错误之前，确保栈帧被干净地展开。如果您试图在数组上使用mem::forget或者只是返回，则MaybeUninit包装器将被丢弃（无操作），但内部的活动T实例将泄漏其资源（如文件句柄或堆内存）。相反，如果您错误地丢弃元素i..N，您将通过将垃圾内存视为有效T实例而引发未定义行为。