在幕后，Rust的std::sync::Mutex is often implemented essentially identically to C++'s std::Mutex（例如，在具有pthreads的系统上，如果没有特定于操作系统的原语更好，则都使用pthread_mutex_lock）. On Linux, April 2022, Rust adopted the use of Linux futexes when available，并且它们在无争用情况下的性能非常高。
Modern mutexes are already designed to operate extremely efficiently when uncontended，通常通过混合用户空间和内核空间锁定（也就是说，如果争用需要阻塞，内核只需要参与），所以如果锁是无争用的，无论如何都可以做得很好。
所以基本上，在99%的情况下，我只会使用std::sync::Mutex。如果您 * 真的 * 为速度而苦恼，并且不能通过原子或类似的方式完全消除锁，the benchmarks for the new futex-based std::sync::Mutex表明spin::Mutex和parking_lot::Mutex在低/无争用场景中略优于它，但作为交换，它们会失败（在parking_lot::Mutex的情况下，* 严重 * 失败）。对于低/无争用，spin::Mutex似乎是最佳选择（无争用时开销大约降低35%，低争用时降低25%），但std::sync::Mutex赢得了激烈的竞争，（在极端竞争下有一个巨大的优势），所以如果你不确定竞争是轻的，我不会在一个低成本的场景中取得一个小的胜利，而在一个已经很高成本的场景中，这可能会成为一个大的损失。还要注意，spin::Mutex是，AFAICT，一个自旋锁，* 不 * 使用内核支持阻塞，因此，阻塞它的线程通常会浪费大量的CPU，试图一遍又一遍地获取它;如果你的代码在电池供电的设备上运行，你会伤害你的用户。
也就是说，这些基准测试是特定于现代Linux系统的。在实践中，如果这对您真的很重要，您需要在您计划实际支持的系统上进行基准测试。