历史。 ManuallyDrop<T> 在 Rust 1.20 中出现，作为一种零成本包装器，旨在显式禁止自动析构函数调用，作为处理部分初始化数据或实现复杂容器类型时，比 mem::forget 更安全和更具语义清晰性的替代方案。与 MaybeUninit<T> 不同的是，后者管理可能尚未包含有效 T 实例的内存，ManuallyDrop 假设内部值始终完全初始化，但将析构的时机推迟到程序员的裁量权。这一区别在为集合类型实现自定义 Drop 特性时至关重要，因为 ManuallyDrop 允许在析构过程中逐字段提取，而不会触发双重丢弃错误或需要 Option<T> 的运行时开销。
问题。 考虑一个场景，其中一个通用容器必须在其析构周期中排空元素，或者在原地构造期间从恐慌中恢复；标准的 Drop 实现无法从 self 中移动值，因为编译器仍然会尝试在 Drop 实现完成后丢弃已移动的来源。尽管 Option<T> 与 take() 提供了一种安全的替代方案，但它引入了运行时开销（判别布尔变量），并且要求 T 初始构造为 Option，这违反了零成本抽象原则。ManuallyDrop 提供了一种在编译时具有保证的包装器，与 T 本身的内存布局相同，能够通过 ptr::read 直接提取字段，而无需额外的空间分配或分支惩罚。
解决方案。 该包装器通过其 #[repr(transparent)] 属性禁用 T 的析构函数的自动调用，要求显式不安全调用 ManuallyDrop::drop 来运行析构函数。当实现包含堆分配资源的结构的 Drop 时，您可以将敏感字段包装在 ManuallyDrop 中，允许在手动清理之前提取内部值。在调用 drop 后访问内部值构成立即的未定义行为，因为该值在逻辑上变得未初始化，尽管仍在内存中，可能包含悬挂指针，如果 T 拥有堆内存。该模式对于像 Vec::drop 这样的零成本抽象至关重要，必须在防止元素丢弃的同时解除后备存储的分配，如果由于容量溢出而提取失败。
use std::mem::ManuallyDrop; use std::ptr; struct Buffer<T> { // 指向堆分配的原始指针 ptr: *mut T, // ManuallyDrop 允许我们提取 Vec 而不自动丢弃 temp_storage: ManuallyDrop<Vec<T>>, } impl<T> Drop for Buffer<T> { fn drop(&mut self) { // 安全提取 ManuallyDrop 中的 Vec let vec = unsafe { ptr::read(&*self.temp_storage) }; // 手动丢弃以防止 Vec 的双重丢弃 unsafe { ManuallyDrop::drop(&mut self.temp_storage) }; // 现在我们可以使用 vec，而不必担心编译器再次尝试丢弃 self.temp_storage drop(vec); } }
问题描述。 在为运行在 128KB RAM 微控制器上的高性能无锁队列开发过程中，我们在队列的 Drop 实现中遇到了一个关键问题。该队列使用了一个侵入式链表，其中节点包含 Box<Node<T>> 指针，我们需要在不通过标准 Drop 实现递归遍历的情况下排空 10,000+ 个节点（这会在我们的受限环境中导致堆栈溢出）。此外，一些节点可能在并发 push 操作期间处于中间初始化状态，当出现恐慌时，需要我们有选择地销毁仅完全初始化的节点，同时泄漏部分构造的节点以维护安全性。
解决方案 1：使用 Option 和 take。 我们最初将每个节点指针包装在 Option<Box<Node<T>>> 中，并使用 while let Some(node) = head.take() 来排空列表。 优点： 完全安全，符合习惯用法的 Rust，不需要不安全代码，且易于维护。 缺点： 每个节点包含一个额外字节用于 Option 判别符，在我们的嵌入式上下文中内存占用增加了大约 12%，而 take() 操作在热门路径中引入了分支预测惩罚，在基准测试中降低了 8% 的吞吐量。
解决方案 2：使用 mem::forget。 我们考虑使用 std::mem::forget 对整个队列结构防止自动丢弃，然后使用 alloc::dealloc 手动释放内存。 优点： 防止递归丢弃并避免 Option 开销。 缺点： 极其不安全，需要手动内存管理，绕过 Rust 的分配器安全检查，如果手动释放失败，将导致内存泄漏，且使得对未来不熟悉原始指针算术的开发人员的代码变得难以维护。
解决方案 3：ManuallyDrop 字段。 我们重新设计了 Node 结构，将其 next 指针存储为 ManuallyDrop<Box<Node<T>>>。在 Drop 中，我们使用原始指针操作迭代遍历列表，通过 ptr::read 提取每个 Box，移动到局部变量，并在通过原子状态标志验证节点完全初始化后，显式调用 ManuallyDrop::drop 仅在提取的槽上。 优点： 零内存开销（ManuallyDrop 是 #[repr(transparent)]），对析构顺序的完全控制，能够安全处理部分初始化的节点，通过跳过未初始化节点的手动丢弃。 缺点： 需要 unsafe 块，并且需要高级工程师仔细审核不变性。
选择了哪个解决方案以及原因。 我们选择了解决方案 3 （ManuallyDrop），因为嵌入式系统对 RAM 的严格限制使得 Option 的开销对于我们 10,000 节点的容量要求不可接受，而 mem::forget 对于生产代码来说太容易出错。 ManuallyDrop 使我们能够维护 Rust 的内存安全保证，同时为侵入式数据结构提供所需的精确控制。我们将不安全操作包装在一个小且经过充分测试的模块中，并在测试构建中使用 debug_assertions 验证不变性，并对安全不变性进行了广泛文档记录。
结果。 该队列成功处理了最大容量的链条而没有堆栈溢出，无论链条长度如何保持恒定内存使用，并通过 Miri（中级中间表示解释器）验证，确认没有未定义行为。显式的手动丢弃调用使析构逻辑立即可见给代码审查人员，防止了早期 C++ 实现同一数据结构中存在的微妙双重丢弃错误。
问题：为什么在调用 ManuallyDrop::drop 后，ManuallyDrop<T> 的内部值必须被视为逻辑上不可访问，以及为什么 Rust 编译器在编译时不强制执行此限制？
答案。 一旦调用 ManuallyDrop::drop，内部值过渡到逻辑未初始化状态，类似于 MaybeUninit 在初始化之前。编译器无法在编译时强制执行这一点，因为 ManuallyDrop 旨在用于像 Drop 实现这样的上下文，在这些上下文中借用检查器已经允许通过 &mut self 引用复杂地修改 self。该包装器故意保留其 DerefMut 实现，即使在丢弃后也支持某些原子操作模式，这意味着编译器在类型级别没有内置的“已丢弃”概念。在丢弃后访问内部值构成立即的未定义行为，因为析构函数可能已经释放了资源（例如堆内存或文件描述符），使得包装器包含悬挂指针或无效的位模式。
问题： ManuallyDrop 如何影响所包装类型 T 的 Send 和 Sync 特征自动实现，以及这对于并发数据结构为什么至关重要？**
答案。 ManuallyDrop<T> 带有 #[repr(transparent)] 属性，这意味着它具有与 T 相同的内存布局和 ABI，且仅在 T 实现时才有条件地实现 Send 和 Sync。候选人常常错误地认为抑制析构函数在某种程度上削弱了线程安全保证或增加了像 UnsafeCell 这样的内部可变性。实际上，ManuallyDrop 保留了所有自动特质实现，因为它没有引入任何同步开销或共享可变状态。这意味着在多个线程中共享 &ManuallyDrop<T> 的安全要求与共享 &T 相同；只有在您修改值或调用手动丢弃时，才会出现不安全问题，此时标准的所有权规则和独占可变访问要求严格适用。
问题：为什么在 Drop 实现中使用 ptr::read 从 ManuallyDrop 字段提取值比在常规字段上使用 ptr::read 更安全，以及它预防了什么特定的双重丢弃场景？
答案。 当您在常规字段上使用 ptr::read 时，您创建了值的按位副本，但原始内存位置在编译器的丢弃检查分析中仍然“存活”。当当前的 Drop 范围结束时，编译器自动为所有字段插入析构函数调用，包括您刚刚读取的字段，导致在其范围结束时发生双重丢弃（使用后释放），因为复制的值也会被丢弃。通过将字段包装在 ManuallyDrop 中，您向编译器信号表明，当父结构丢弃时，此字段不应自动销毁。因此，在 ptr::read 后，您可以安全地获得复制值的所有权，而不会引发编译器尝试丢弃源，因为 ManuallyDrop 抑制了该自动调用，有效地充当了在 Drop 过程中搬出的“许可单”，而不会违反别名规则。