Mutex 污染利用锁的内部状态中的一个布尔标志，该标志在持有保护时发生恐慌时原子地设置为 true。在展开阶段，保护的 Drop 实现通过 std::thread::panicking() 检测到恐慌线程，并在释放底层操作系统锁之前将 Mutex 标记为污染。后续对 lock() 的调用检查此标志；如果设置，则返回 Err(PoisonError<MutexGuard<T>>) 而不是 Ok，强迫调用者承认受保护数据可能因恐慌导致的部分修改而违反其结构不变性。
在一个分布式文档处理引擎中，一个后台工作线程持有一个 Mutex，保护一个较大的 DocumentCache，同时执行复杂的格式化例程。在更新缓存的内部 BTreeMap 索引的过程中，由于意外的格式错误输入，线程发生了恐慌。展开机制触发了保护的 Drop 实现，该实现检测到恐慌状态，并在释放操作系统级别锁之前原子性地污染 Mutex，确保其他工作线程在没有明确确认的情况下无法访问损坏的部分树结构。
一种潜在的恢复策略是在下一个锁获取期间立即终止进程，以检测到毒化错误。这确保没有损坏的数据进入持久存储或客户端响应，满足严格的完整性要求。然而，这种方法牺牲了可用性，因为它强制整个服务冷启动，并丢弃所有由无关线程执行的有效工作，在高负载处理窗口期间造成不可接受的停机时间。
第二种方法使用 PoisonError::into_inner() 来提取保护并继续操作，有效地忽略毒物标志，假设数据可能在结构上是可靠的。虽然这保留了正常运行时间，但当后续读取遇到悬空指针或由恐慌线程留下的不变性违反时，会冒着灾难性级联故障的风险，可能导致次级恐慌或静默数据损坏，传播到后续分析管道和持久数据库中。
所选解决方案实现了事务回滚机制：在捕获毒化错误时，系统明确删除受污染的 DocumentCache，从存储在单独 NVMe 卷上的 Write-Ahead Log (WAL) 中恢复一个已知良好的不可变快照，并生成具有干净状态的新工作线程。这种方法将故障隔离到单个文档批次，同时为其他客户端保留服务的可用性，确保受损内存不会被应用逻辑取消引用。经过激烈的模糊测试，结果是 99.99% 的正常运行时间指标，自动恢复在 50 毫秒内完成，远超文档处理延迟的严格 SLA 要求。
为什么 RwLock 也实现了污染，而标准库的 Mutex 通常更倾向于保护简单的 Copy 类型？
RwLock 保护与 Mutex 相同的复杂不变性，但它的污染扩展到读和写保护，因为恐慌的写者可能会破坏后续读者观察到的状态。然而，对于像整数这样的简单 Copy 类型，Mutex 被优先考虑，而不是因为污染差异——两者的污染是相同的——而是因为 Mutex 在无竞争访问时提供了更低的开销。此外，对于 Copy 类型，污染在语义上是无关的，因为它们不能表现出内部不变性违反；在赋值过程中发生恐慌仅会使旧值保持不变，使得通过覆盖来恢复变得简单，无需复杂的验证逻辑。
std::sync::PoisonError::new 与内部污染机制有何不同，为什么手动构造未污染的 Mutex 的毒化保护是不安全的？
PoisonError::new 是一个公共构造函数，允许手动创建错误变体，但它并不会实际修改底层 Mutex 的内部毒物标志；它只是将保护包装在错误类型中以保持 API 兼容性。在应用程序流程中手动注入此类错误会绕过编译器强制的安全性，要求显式处理毒物状态，可能允许访问其他线程同时尝试重建的数据。如果手动构造与合法的污染逻辑重合，这会造成数据竞争，因为两个线程可能同时认为它们拥有独占的恢复权，从而导致在状态重置期间出现双重释放或使用后释放的场景。
在不销毁 Mutex 的情况下，污染可以安全地“清除”吗？PoisonError::into_inner() 对内存安全保证有什么暗示？
虽然 into_inner() 提取保护并丢弃错误包装，但并不会清除 Mutex 的内部污染状态；该锁仍永久污染，直到 Mutex 自身被丢弃并重新创建。这意味着通过 into_inner() 访问的任何数据都必须被视为可能违反其类型的不变性，需在重用之前完全手动验证或重建受保护的状态。候选人常常忽视 into_inner() 提供的没有自动恢复；它仅仅是用对潜在危险内存的原始访问替代 Err 变体的安全性，要求用 unsafe 逻辑恢复不变性，然后数据才可以再次被视为安全以供一般使用。