使用 Sync 和 Send Trait 实现可扩展并发
有趣的是，Rust 语言的并发特性非常少。到目前为止，我们在本章中讨论的几乎所有并发特性都是标准库的一部分，而不是语言本身的一部分。您处理并发的选择并不局限于语言或标准库；您可以编写自己的并发特性，也可以使用其他人编写的特性。
但是，有两个并发概念是嵌入在语言中的：std::marker 特征 Sync 和 Send。
使用 Send 允许在线程之间转移所有权
Send 标记特征表明，实现 Send 的类型的值的所有权可以在线程之间转移。几乎所有 Rust 类型都是 Send，但也有一些例外，包括 Rc<T>：它不能是 Send，因为如果您克隆了一个 Rc<T> 值并尝试将克隆的所有权转移到另一个线程，则两个线程可能会同时更新引用计数。因此，Rc<T> 是为在单线程情况下实现的，在这些情况下，您不希望付出线程安全的性能损失。
因此，Rust 的类型系统和特征边界确保您永远不会意外地将 Rc<T> 值不安全地跨线程发送。当我们在代码清单 16-14 中尝试这样做时，我们得到了错误 the trait Send is not implemented for Rc<Mutex<i32>>。当我们切换到 Arc<T> 时，它是 Send，代码编译成功。
任何完全由 Send 类型组成的类型也会自动标记为 Send。几乎所有基本类型都是 Send，除了原始指针，我们将在第 19 章中讨论。
使用 Sync 允许多线程访问
Sync 标记特征表明，从多个线程引用实现 Sync 的类型是安全的。换句话说，如果 &T（对 T 的不可变引用）是 Send，则任何类型 T 都是 Sync，这意味着该引用可以安全地发送到另一个线程。与 Send 类似，基本类型是 Sync，并且完全由 Sync 类型组成的类型也是 Sync。
智能指针 Rc<T> 也不是 Sync，原因与它不是 Send 相同。RefCell<T> 类型（我们在第 15 章中讨论过）和相关的 Cell<T> 类型家族都不是 Sync。RefCell<T> 在运行时进行的借用检查的实现不是线程安全的。智能指针 Mutex<T> 是 Sync，并且可以用于与多个线程共享访问，如您在“在多个线程之间共享 Mutex<T>”部分中所见。
手动实现 Send 和 Sync 是不安全的
因为由 Send 和 Sync trait 组成的类型自动也是 Send 和 Sync，所以我们不必手动实现这些 trait。作为标记 trait，它们甚至没有任何要实现的方法。它们仅用于强制执行与并发相关的约束。
手动实现这些 trait 涉及实现 unsafe Rust 代码。我们将在第 19 章讨论 unsafe Rust 代码的使用；现在，重要信息是构建由 Send 和 Sync 部分组成的新并发类型需要仔细考虑以维护安全保证。《Rust 秘典》中有更多关于这些保证以及如何维护它们的信息。
总结
这并不是您在本书中最后一次看到并发：第 20 章中的项目将在比此处讨论的较小示例更现实的情况下使用本章中的概念。
如前所述，由于 Rust 处理并发的很少一部分是语言的一部分，因此许多并发解决方案都是作为 crate 实现的。这些 crate 的发展速度比标准库快，因此请务必在线搜索要在多线程情况下使用的最新、最先进的 crate。
Rust 标准库提供了用于消息传递的通道和智能指针类型，例如 Mutex<T> 和 Arc<T>，它们可以在并发上下文中安全使用。类型系统和借用检查器确保使用这些解决方案的代码不会出现数据竞争或无效引用。一旦您的代码编译完成，您就可以放心，它将在多个线程上顺利运行，而不会出现其他语言中常见的难以追踪的错误。并发编程不再是一个可怕的概念：勇敢地前进，让您的程序并发运行吧！
接下来，我们将讨论随着 Rust 程序变得更大，对问题进行建模和构建解决方案的惯用方法。此外，我们还将讨论 Rust 的惯用方法与您可能熟悉的面向对象编程中的惯用方法之间的关系。