|
|
## 使用线程同时运行代码
|
|
|
|
|
|
> [ch16-01-threads.md](https://github.com/rust-lang/book/blob/main/src/ch16-01-threads.md) <br>
|
|
|
> commit 6b9eae8ce91dd0d94982795762d22077d372e90c
|
|
|
|
|
|
在大部分现代操作系统中，已执行程序的代码在一个 **进程**（_process_）中运行，操作系统则负责管理多个进程。在程序内部，也可以拥有多个同时运行的独立部分。运行这些独立部分的功能被称为 **线程**（_threads_）。
|
|
|
|
|
|
将程序中的计算拆分进多个线程可以改善性能，因为程序可以同时进行多个任务，不过这也会增加复杂性。因为线程是同时运行的，所以无法预先保证不同线程中的代码的执行顺序。这会导致诸如此类的问题：
|
|
|
|
|
|
- 竞态条件（Race conditions），多个线程以不一致的顺序访问数据或资源
|
|
|
- 死锁（Deadlocks），两个线程相互等待对方停止使用其所拥有的资源，这会阻止它们继续运行
|
|
|
- 只会发生在特定情况且难以稳定重现和修复的 bug
|
|
|
|
|
|
Rust 尝试减轻使用线程的负面影响。不过在多线程上下文中编程仍需格外小心，同时其所要求的代码结构也不同于运行于单线程的程序。
|
|
|
|
|
|
编程语言有一些不同的方法来实现线程。很多操作系统提供了创建新线程的 API。这种由编程语言调用操作系统 API 创建线程的模型有时被称为 *1:1*，一个 OS 线程对应一个语言线程。Rust 标准库只提供了 1:1 线程实现；有一些 crate 实现了其他有着不同取舍的线程模型。
|
|
|
|
|
|
### 使用 `spawn` 创建新线程
|
|
|
|
|
|
为了创建一个新线程，需要调用 `thread::spawn` 函数并传递一个闭包（第十三章学习了闭包），并在其中包含希望在新线程运行的代码。示例 16-1 中的例子在主线程打印了一些文本而另一些文本则由新线程打印：
|
|
|
|
|
|
<span class="filename">文件名: src/main.rs</span>
|
|
|
|
|
|
```rust
|
|
|
{{#rustdoc_include ../listings/ch16-fearless-concurrency/listing-16-01/src/main.rs}}
|
|
|
```
|
|
|
|
|
|
<span class="caption">示例 16-1: 创建一个打印某些内容的新线程，但是主线程打印其它内容</span>
|
|
|
|
|
|
注意这个函数编写的方式，当主线程结束时，新线程也会结束，而不管其是否执行完毕。这个程序的输出可能每次都略有不同，不过它大体上看起来像这样：
|
|
|
|
|
|
```text
|
|
|
hi number 1 from the main thread!
|
|
|
hi number 1 from the spawned thread!
|
|
|
hi number 2 from the main thread!
|
|
|
hi number 2 from the spawned thread!
|
|
|
hi number 3 from the main thread!
|
|
|
hi number 3 from the spawned thread!
|
|
|
hi number 4 from the main thread!
|
|
|
hi number 4 from the spawned thread!
|
|
|
hi number 5 from the spawned thread!
|
|
|
```
|
|
|
|
|
|
`thread::sleep` 调用强制线程停止执行一小段时间，这会允许其他不同的线程运行。这些线程可能会轮流运行，不过并不保证如此：这依赖操作系统如何调度线程。在这里，主线程首先打印，即便新创建线程的打印语句位于程序的开头，甚至即便我们告诉新建的线程打印直到 `i` 等于 9 ，它在主线程结束之前也只打印到了 5。
|
|
|
|
|
|
如果运行代码只看到了主线程的输出，或没有出现重叠打印的现象，尝试增大区间 (变量 `i` 的范围) 来增加操作系统切换线程的机会。
|
|
|
|
|
|
#### 使用 `join` 等待所有线程结束
|
|
|
|
|
|
由于主线程结束，示例 16-1 中的代码大部分时候不光会提早结束新建线程，甚至不能实际保证新建线程会被执行。其原因在于无法保证线程运行的顺序！
|
|
|
|
|
|
可以通过将 `thread::spawn` 的返回值储存在变量中来修复新建线程部分没有执行或者完全没有执行的问题。`thread::spawn` 的返回值类型是 `JoinHandle`。`JoinHandle` 是一个拥有所有权的值，当对其调用 `join` 方法时，它会等待其线程结束。示例 16-2 展示了如何使用示例 16-1 中创建的线程的 `JoinHandle` 并调用 `join` 来确保新建线程在 `main` 退出前结束运行：
|
|
|
|
|
|
<span class="filename">文件名: src/main.rs</span>
|
|
|
|
|
|
```rust
|
|
|
{{#rustdoc_include ../listings/ch16-fearless-concurrency/listing-16-02/src/main.rs}}
|
|
|
```
|
|
|
|
|
|
<span class="caption">示例 16-2: 从 `thread::spawn` 保存一个 `JoinHandle` 以确保该线程能够运行至结束</span>
|
|
|
|
|
|
通过调用 handle 的 `join` 会阻塞当前线程直到 handle 所代表的线程结束。**阻塞**（_Blocking_） 线程意味着阻止该线程执行工作或退出。因为我们将 `join` 调用放在了主线程的 `for` 循环之后，运行示例 16-2 应该会产生类似这样的输出：
|
|
|
|
|
|
```text
|
|
|
hi number 1 from the main thread!
|
|
|
hi number 2 from the main thread!
|
|
|
hi number 1 from the spawned thread!
|
|
|
hi number 3 from the main thread!
|
|
|
hi number 2 from the spawned thread!
|
|
|
hi number 4 from the main thread!
|
|
|
hi number 3 from the spawned thread!
|
|
|
hi number 4 from the spawned thread!
|
|
|
hi number 5 from the spawned thread!
|
|
|
hi number 6 from the spawned thread!
|
|
|
hi number 7 from the spawned thread!
|
|
|
hi number 8 from the spawned thread!
|
|
|
hi number 9 from the spawned thread!
|
|
|
```
|
|
|
|
|
|
这两个线程仍然会交替执行，不过主线程会由于 `handle.join()` 调用会等待直到新建线程执行完毕。
|
|
|
|
|
|
不过让我们看看将 `handle.join()` 移动到 `main` 中 `for` 循环之前会发生什么，如下：
|
|
|
|
|
|
<span class="filename">文件名: src/main.rs</span>
|
|
|
|
|
|
```rust
|
|
|
{{#rustdoc_include ../listings/ch16-fearless-concurrency/no-listing-01-join-too-early/src/main.rs}}
|
|
|
```
|
|
|
|
|
|
主线程会等待直到新建线程执行完毕之后才开始执行 `for` 循环，所以输出将不会交替出现，如下所示：
|
|
|
|
|
|
```text
|
|
|
hi number 1 from the spawned thread!
|
|
|
hi number 2 from the spawned thread!
|
|
|
hi number 3 from the spawned thread!
|
|
|
hi number 4 from the spawned thread!
|
|
|
hi number 5 from the spawned thread!
|
|
|
hi number 6 from the spawned thread!
|
|
|
hi number 7 from the spawned thread!
|
|
|
hi number 8 from the spawned thread!
|
|
|
hi number 9 from the spawned thread!
|
|
|
hi number 1 from the main thread!
|
|
|
hi number 2 from the main thread!
|
|
|
hi number 3 from the main thread!
|
|
|
hi number 4 from the main thread!
|
|
|
```
|
|
|
|
|
|
诸如将 `join` 放置于何处这样的小细节，会影响线程是否同时运行。
|
|
|
|
|
|
### 线程与 `move` 闭包
|
|
|
|
|
|
`move` 关键字经常用于传递给 `thread::spawn` 的闭包，因为闭包会获取从环境中取得的值的所有权，因此会将这些值的所有权从一个线程传送到另一个线程。在第十三章 [“闭包会捕获其环境”][capture] 部分讨论了闭包上下文中的 `move`。现在我们会更专注于 `move` 和 `thread::spawn` 之间的交互。
|
|
|
|
|
|
在第十三章中，我们讲到可以在参数列表前使用 `move` 关键字强制闭包获取其使用的环境值的所有权。这个技巧在创建新线程将值的所有权从一个线程移动到另一个线程时最为实用。
|
|
|
|
|
|
注意示例 16-1 中传递给 `thread::spawn` 的闭包并没有任何参数：并没有在新建线程代码中使用任何主线程的数据。为了在新建线程中使用来自于主线程的数据，需要新建线程的闭包获取它需要的值。示例 16-3 展示了一个尝试在主线程中创建一个 vector 并用于新建线程的例子，不过这么写还不能工作，如下所示：
|
|
|
|
|
|
<span class="filename">文件名: src/main.rs</span>
|
|
|
|
|
|
```rust,ignore,does_not_compile
|
|
|
{{#rustdoc_include ../listings/ch16-fearless-concurrency/listing-16-03/src/main.rs}}
|
|
|
```
|
|
|
|
|
|
<span class="caption">示例 16-3: 尝试在另一个线程使用主线程创建的 vector</span>
|
|
|
|
|
|
闭包使用了 `v`，所以闭包会捕获 `v` 并使其成为闭包环境的一部分。因为 `thread::spawn` 在一个新线程中运行这个闭包，所以可以在新线程中访问 `v`。然而当编译这个例子时，会得到如下错误：
|
|
|
|
|
|
```console
|
|
|
{{#include ../listings/ch16-fearless-concurrency/listing-16-03/output.txt}}
|
|
|
```
|
|
|
|
|
|
Rust 会 **推断** 如何捕获 `v`，因为 `println!` 只需要 `v` 的引用，闭包尝试借用 `v`。然而这有一个问题：Rust 不知道这个新建线程会执行多久，所以无法知晓 `v` 的引用是否一直有效。
|
|
|
|
|
|
示例 16-4 展示了一个 `v` 的引用很有可能不再有效的场景：
|
|
|
|
|
|
<span class="filename">文件名: src/main.rs</span>
|
|
|
|
|
|
```rust,ignore,does_not_compile
|
|
|
{{#rustdoc_include ../listings/ch16-fearless-concurrency/listing-16-04/src/main.rs}}
|
|
|
```
|
|
|
|
|
|
<span class="caption">示例 16-4: 一个具有闭包的线程，尝试使用一个在主线程中被回收的引用 `v`</span>
|
|
|
|
|
|
假如这段代码能正常运行的话，则新建线程则可能会立刻被转移到后台并完全没有机会运行。新建线程内部有一个 `v` 的引用，不过主线程立刻就使用第十五章讨论的 `drop` 丢弃了 `v`。接着当新建线程开始执行，`v` 已不再有效，所以其引用也是无效的。噢，这太糟了！
|
|
|
|
|
|
为了修复示例 16-3 的编译错误，我们可以听取错误信息的建议：
|
|
|
|
|
|
```text
|
|
|
help: to force the closure to take ownership of `v` (and any other referenced variables), use the `move` keyword
|
|
|
|
|
|
|
6 | let handle = thread::spawn(move || {
|
|
|
| ++++
|
|
|
```
|
|
|
|
|
|
通过在闭包之前增加 `move` 关键字，我们强制闭包获取其使用的值的所有权，而不是任由 Rust 推断它应该借用值。示例 16-5 中展示的对示例 16-3 代码的修改，可以按照我们的预期编译并运行：
|
|
|
|
|
|
<span class="filename">文件名: src/main.rs</span>
|
|
|
|
|
|
```rust
|
|
|
{{#rustdoc_include ../listings/ch16-fearless-concurrency/listing-16-05/src/main.rs}}
|
|
|
```
|
|
|
|
|
|
<span class="caption">示例 16-5: 使用 `move` 关键字强制获取它使用的值的所有权</span>
|
|
|
|
|
|
那么如果使用了 `move` 闭包，示例 16-4 中主线程调用了 `drop` 的代码会发生什么呢？加了 `move` 就搞定了吗？不幸的是，我们会得到一个不同的错误，因为示例 16-4 所尝试的操作由于一个不同的原因而不被允许。如果为闭包增加 `move`，将会把 `v` 移动进闭包的环境中，如此将不能在主线程中对其调用 `drop` 了。我们会得到如下不同的编译错误：
|
|
|
|
|
|
```console
|
|
|
{{#include ../listings/ch16-fearless-concurrency/output-only-01-move-drop/output.txt}}
|
|
|
```
|
|
|
|
|
|
Rust 的所有权规则又一次帮助了我们！示例 16-3 中的错误是因为 Rust 是保守的并只会为线程借用 `v`，这意味着主线程理论上可能使新建线程的引用无效。通过告诉 Rust 将 `v` 的所有权移动到新建线程，我们向 Rust 保证主线程不会再使用 `v`。如果对示例 16-4 也做出如此修改，那么当在主线程中使用 `v` 时就会违反所有权规则。 `move` 关键字覆盖了 Rust 默认保守的借用，但它不允许我们违反所有权规则。
|
|
|
|
|
|
现在我们对线程和线程 API 有了基本的了解，让我们讨论一下使用线程实际可以 **做** 什么吧。
|
|
|
|
|
|
[capture]: ch13-01-closures.html#闭包会捕获其环境
|
