Update cell-refcell.md

26行，没理解为什么违背了Rust的借用规则。
86行，RefCell 用于引用没读懂，前面例子中展示的是RefCell中存放一个String，这里为什么说是引用？
237行，数据结构和CPU亲和是啥意思，第一次听到这种描述

book/contents/advance/smart-pointer/cell-refcell.md

@@ -1,12 +1,12 @@
 # Cell 和 RefCell
 Rust 的编译器之严格，可以说是举世无双。特别是在所有权方面，Rust 通过严格的规则来保证所有权和借用的正确性，最终为程序的安全保驾护航。
 
-但是严格是一把双刃剑，带来安全提升的同时，损失了灵活性，有时甚至会让用户痛苦不堪、怨声载道。因此Rust提供了`Cell`和`RefCell`用于内部可变性, 简而言之，可以在拥有不可变引用的同时修改目标数据，对于正常的代码实现来说，这个是不可能做到的(要么一个可变借用，要么多个不可变借用).
+但是严格是一把双刃剑，带来安全提升的同时，损失了灵活性，有时甚至会让用户痛苦不堪、怨声载道。因此 Rust 提供了 `Cell` 和 `RefCell` 用于内部可变性，简而言之，可以在拥有不可变引用的同时修改目标数据，对于正常的代码实现来说，这个是不可能做到的(要么一个可变借用，要么多个不可变借用)。
 
 > 内部可变性的实现是因为 Rust 使用了 `unsafe` 来做到这一点，但是对于使用者来说，这些都是透明的，因为这些不安全代码都被封装到了安全的 API 中
 
 ## Cell
-Cell和RefCell在功能上没有区别，区别在于`Cell<T>`适用于`T`实现`Copy`的情况:
+`Cell` 和 `RefCell` 在功能上没有区别，区别在于 `Cell<T>` 适用于 `T` 实现 `Copy` 的情况：
 ```rust
 use std::cell::Cell;
 fn main() {
@@ -18,17 +18,17 @@ fn main() {
 }
 ```
 
-以上代码展示了`Cell`的基本用法，有几点值得注意:
+以上代码展示了 `Cell` 的基本用法，有几点值得注意：
 
 - "asdf" 是 `&str` 类型，它实现了 `Copy` 特征
 - `c.get` 用来取值，`c.set` 用来设置新值
 
-取到值保存在`one`变量后，还能同时进行修改，这个违背了Rust的借用规则，但是由于`Cell`的存在，我们很优雅的做到了这一点，但是如果你尝试在`Cell`中存放`String`：
+取到值保存在 `one` 变量后，还能同时进行修改，这个违背了 Rust 的借用规则，但是由于 `Cell` 的存在，我们很优雅地做到了这一点，但是如果你尝试在 `Cell` 中存放`String`：
 ```rust
  let c = Cell::new(String::from("asdf"));
  ```
 
-编译器会立刻报错，因为`String`没有实现`Copy`特征:
+编译器会立刻报错，因为 `String` 没有实现 `Copy` 特征：
 ```console
 | pub struct String {
 | ----------------- doesn't satisfy `String: Copy`
@@ -40,7 +40,7 @@ fn main() {
 ## RefCell
 由于 `Cell` 类型针对的是实现了 `Copy` 特征的值类型，因此在实际开发中，`Cell` 使用的并不多，因为我们要解决的往往是可变、不可变引用共存导致的问题，此时就需要借助于 `RefCell` 来达成目的。
 
-我们可以将所有权、借用规则与这些智能指针做一个对比:
+我们可以将所有权、借用规则与这些智能指针做一个对比：
 
 | Rust规则 | 智能指针带来的额外规则 |
 |--------|-------------|
@@ -48,7 +48,7 @@ fn main() {
 | 要么多个不可变借用，要么一个可变借用 | `RefCell`实现编译期可变、不可变引用共存 |
 | 违背规则导致**编译错误** | 违背规则导致**运行时`panic`** | 
 
-可以看出，`Rc/Arc`和`RefCell`合在一起，解决了Rust中严苛的所有权和借用规则带来的某些场景下难使用的问题。但是它们并不是银弹，例如`RefCell`实际上并没有解决可变引用和引用可以共存的问题，只是将报错从编译期推迟到运行时，从编译器错误变成了`panic`异常:
+可以看出，`Rc/Arc` 和 `RefCell` 合在一起，解决了 Rust 中严苛的所有权和借用规则带来的某些场景下难使用的问题。但是它们并不是银弹，例如 `RefCell` 实际上并没有解决可变引用和引用可以共存的问题，只是将报错从编译期推迟到运行时，从编译器错误变成了 `panic` 异常：
 ```rust
 use std::cell::RefCell;
 
@@ -83,19 +83,19 @@ note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 
 #### RefCell 简单总结
 
-- 与Cell用于可Copy的值不同，RefCell用于引用
-- RefCell只是将借用规则从编译期推迟到程序运行期，并不能帮你绕过这个规则
-- RefCell适用于编译期误报或者一个引用被在多个代码中使用、修改以至于难于管理借用关系时
+- 与 `Cell` 用于可 `Copy` 的值不同，`RefCell` 用于引用
+- `RefCell` 只是将借用规则从编译期推迟到程序运行期，并不能帮你绕过这个规则
+- `RefCell` 适用于编译期误报或者一个引用被在多处代码使用、修改以至于难于管理借用关系时
 - 使用 `RefCell` 时，违背借用规则会导致运行期的 `panic`
 
 ## 选择 `Cell` 还是 `RefCell`
 根据本文的内容，我们可以大概总结下两者的区别：
 
-- `Cell`只适用于`Copy`类型，用于提供值, 而`RefCell`用于提供引用
+- `Cell` 只适用于 `Copy` 类型，用于提供值，而 `RefCell` 用于提供引用
 - `Cell` 不会 `panic`，而 `RefCell` 会
 
 #### 性能比较
-`Cell`没有额外的性能损耗，例如以下两段代码的性能其实是一致的:
+`Cell` 没有额外的性能损耗，例如以下两段代码的性能其实是一致的：
 ```rust
 // code snipet 1
 let x = Cell::new(1);
@@ -118,14 +118,14 @@ println!("{}", x);
 
 虽然性能一致，但代码 `1` 拥有代码 `2` 不具有的优势：它能编译成功:)
 
-与`Cell`的`zero cost`不同，`RefCell`其实是有一点运行期开销的，原因是它包含了一个字大小的"借用状态"指示器，该指示器在每次运行时借用时都会被修改，进而产生一点开销。
+与 `Cell` 的 `zero cost` 不同，`RefCell` 其实是有一点运行期开销的，原因是它包含了一个字大小的“借用状态”指示器，该指示器在每次运行时借用时都会被修改，进而产生一点开销。
 
 
-总之，当非要使用内部可变性时，首选`Cell`，只有值拷贝的方式不能满足你时，才去选择`RefCell`。
+总之，当非要使用内部可变性时，首选 `Cell`，只有你的类型没有实现 `Copy` 时，才去选择 `RefCell`。
 
 
 ## 内部可变性
-之前我们提到RefCell具有内部可变性，何为内部可变性？简单来说，对一个不可变的值进行可变借用，但这个并不符合Rust的基本借用规则：
+之前我们提到 `RefCell` 具有内部可变性，何为内部可变性？简单来说，对一个不可变的值进行可变借用，但这个并不符合 Rust 的基本借用规则：
 ```rust
 fn main() {
     let x = 5;
@@ -133,9 +133,9 @@ fn main() {
 }
 ```
 
-上面的代码会报错，因为我们不能对一个不可变的值进行可变借用，这会破坏Rust的安全性保证，相反，你可以对一个可变值进行不可变借用。原因是：当值不可变时，可能会有多个不可变的引用指向它，修改其中一个为可变的，会造成可变引用与不可变引用共存的情况；而当值可变时，只会有唯一一个可变引用指向它，将其修改为不可变，那么最终依然是只有一个不可变的引用指向它。
+上面的代码会报错，因为我们不能对一个不可变的值进行可变借用，这会破坏 Rust 的安全性保证，相反，你可以对一个可变值进行不可变借用。原因是：当值不可变时，可能会有多个不可变的引用指向它，此时如果有一个可变引用，会造成可变引用与不可变引用共存的情况；而当值可变时，最多只会有一个可变引用指向它，将其修改为不可变，那么最终依然是只有一个不可变的引用指向它。
 
-虽然基本借用规则是Rust的基石，然而在某些场景中，一个值可以在其方法内部被修改，同时对于其它代码不可变，是很有用的:
+虽然基本借用规则是 Rust 的基石，然而在某些场景中，一个值可以在其方法内部被修改，同时对于其它代码不可变，是很有用的：
 ```rust
 // 定义在外部库中的特征
 pub trait Messenger {
@@ -155,9 +155,9 @@ impl Messenger for MsgQueue {
 }
 ```
 
-如上所示，外部库中定义了一个消息发送器特征`Messenger`，它就一个功能用于发送消息: `fn send(&self, msg: String)`，因为发送消息不需要修改自身，因此原作者在定义时，使用了`&self`的不可变借用, 这个无可厚非。
+如上所示，外部库中定义了一个消息发送器特征 `Messenger`，它就只有一个用于发送消息的功能：`fn send(&self, msg: String)`，因为发送消息不需要修改自身，因此原作者在定义时，使用了 `&self` 的不可变借用，这个无可厚非。
 
-但是问题来了，我们要在自己的代码中使用该特征实现一个异步消息队列，出于性能的考虑，消息先写到本地缓存(内存)中，然后批量发送出去，因此在`send`方法中，需要将消息先行插入到本地缓存`msg_cache`中。但是问题来了，该`send`方法的签名是`&self`，因此上述代码会报错:
+我们要在自己的代码中使用该特征实现一个异步消息队列，出于性能的考虑，消息先写到本地缓存(内存)中，然后批量发送出去，因此在 `send` 方法中，需要将消息先行插入到本地缓存 `msg_cache` 中。但是问题来了，该 `send` 方法的签名是 `&self`，因此上述代码会报错：
 ```console
 error[E0596]: cannot borrow `self.sent_messages` as mutable, as it is behind a `&` reference
   --> src/main.rs:11:9
@@ -169,7 +169,7 @@ error[E0596]: cannot borrow `self.sent_messages` as mutable, as it is behind a `
    |         ^^^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable
 ```
 
-在报错的同时，编译器大聪明还善意的给出了提示：将`&self`修改为`&mut self`，但是。。。我们实现的特征是定义在外部库中，因此该签名根本不能修改。值此危急关头，`RefCell`闪亮登场:
+在报错的同时，编译器大聪明还善意地给出了提示：将 `&self` 修改为 `&mut self`，但是。。。我们实现的特征是定义在外部库中，因此该签名根本不能修改。值此危急关头， `RefCell` 闪亮登场：
 ```rust
 use std::cell::RefCell;
 pub trait Messenger {
@@ -187,7 +187,9 @@ impl Messenger for MsgQueue {
 }
 
 fn main() {
-    let mq = MsgQueue{msg_cache: RefCell::new(Vec::new())};
+    let mq = MsgQueue {
+        msg_cache: RefCell::new(Vec::new()),
+    };
     mq.send("hello, world".to_string());
 }
 ```
@@ -195,7 +197,7 @@ fn main() {
 这个 MQ 功能很弱，但是并不妨碍我们演示内部可变性的核心用法：通过包裹一层 `RefCell`，成功的让 `&self` 中的 `msg_cache` 成为一个可变值，然后实现对其的修改。
 
 ##  Rc + RefCell 组合使用
-在Rust中，一个常见的组合就是`Rc`和`RefCell`在一起使用，前者可以实现一个数据拥有多个所有者，后者可以实现数据的可变性:
+在 Rust 中，一个常见的组合就是 `Rc` 和 `RefCell` 在一起使用，前者可以实现一个数据拥有多个所有者，后者可以实现数据的可变性：
 ```rust
 use std::cell::RefCell;
 use std::rc::Rc;
@@ -212,7 +214,7 @@ fn main() {
 
 ```
 
-上面代码中，我们使用`RefCell<String>`包裹一个字符串,同时通过`Rc`创建了它的三个所有者：`s`,`s1`和`s2`，并且通过其中一个所有者`s2`对字符串内容进行了修改。
+上面代码中，我们使用 `RefCell<String>` 包裹一个字符串,同时通过 `Rc` 创建了它的三个所有者：`s`、`s1`和`s2`，并且通过其中一个所有者 `s2` 对字符串内容进行了修改。
 
 由于 `Rc` 的所有者们共享同一个底层的数据，因此当一个所有者修改了数据时，会导致全部所有者持有的数据都发生了变化。
 
@@ -227,10 +229,10 @@ RefCell { value: "我很善变，还拥有多个主人, on yeah!" }
 #### 性能损耗
 相信这两者组合在一起使用时，很多人会好奇到底性能如何，下面我们来简单分析下。
 
-首先给出一个大概的结论，这两者结合在一起使用的性能其实非常高，大致相当于没有线程安全版本的C++ `std::shared_ptr`指针, 事实上，`C++`这个指针的主要开销也在于原子性这个并发原语上，毕竟线程安全在哪个语言中开销都不小。
+首先给出一个大概的结论，这两者结合在一起使用的性能其实非常高，大致相当于没有线程安全版本的 C++ `std::shared_ptr` 指针，事实上，`C++` 这个指针的主要开销也在于原子性这个并发原语上，毕竟线程安全在哪个语言中开销都不小。
 
 #### 内存损耗
-两者结合的数据结构类似:
+两者结合的数据结构与下面类似：
 ```rust
 struct Wrapper<T> {
     // Rc
@@ -250,30 +252,30 @@ struct Wrapper<T> {
 #### CPU 损耗
 从CPU来看，损耗如下：
 
-- 对`Rc<T>`解引用是免费的(编译期), 但是*带来的间接取值并不免费
+- 对 `Rc<T>` 解引用是免费的(编译期)，但是*带来的间接取值并不免费
 - 克隆 `Rc<T>` 需要将当前的引用计数跟 `0` 和 `usize::Max` 进行一次比较，然后将计数值加1
-- 释放(drop)`Rc<T>`将计数值减1， 然后跟`0`进行一次比较
-- 对`RefCell`进行不可变借用，将`isize`类型的借用计数加1，然后跟`0`进行比较
-- 对`RefCell`的不可变借用进行释放，将`isize`减1
-- 对`RefCell`的可变借用大致流程跟上面差不多，但是是先跟`0`比较，然后再减1
-- 对`RefCell`的可变借用进行释放，将`isize`加1
+- 释放 (drop)`Rc<T>` 需要将计数值减1， 然后跟 `0` 进行一次比较
+- 对 `RefCell` 进行不可变借用，需要将 `isize` 类型的借用计数加1，然后跟 `0` 进行比较
+- 对 `RefCell `的不可变借用进行释放，需要将 `isize` 减1
+- 对 `RefCell` 的可变借用大致流程跟上面差不多，但是需要先跟 `0` 比较，然后再减1
+- 对 `RefCell` 的可变借用进行释放，需要将 `isize` 加1
 
 其实这些细节不必过于关注，只要知道 `CPU` 消耗也非常低，甚至编译器还会对此进行进一步优化！
 
 
 #### CPU 缓存 Miss
-唯一需要担心的可能就是这种组合数据结构对于`CPU`缓存是否亲和，这个我们无法证明，只能提出来存在这个可能性，最终的性能影响还需要在实际场景中进行测试
+唯一需要担心的可能就是这种组合数据结构对于 `CPU` 缓存是否亲和，这个我们无法证明，只能提出来存在这个可能性，最终的性能影响还需要在实际场景中进行测试。
 
-总之，分析这两者组合的性能还挺复杂的，大概总结下:
+总之，分析这两者组合的性能还挺复杂的，大概总结下：
 
 - 从表面来看，它们带来的内存和 CPU 损耗都不大
 - 但是由于 `Rc` 额外的引入了一次间接取值(*)，在少数场景下可能会造成性能上的显著损失
 - CPU 缓存可能也不够亲和
 
 ## 通过 `Cell::from_mut` 解决借用冲突
-在Rust1.37版本中新增了两个非常实用的方法:
+在 Rust1.37 版本中新增了两个非常实用的方法：
 
-- Cell::from_mut, 该方法将`&mut T`转为`&Cell<T>`
+- Cell::from_mut，该方法将 `&mut T` 转为 `&Cell<T>`
 - Cell::as_slice_of_cells，该方法将 `&Cell<[T]>` 转为 `&[Cell<T>]`
 
 这里我们不做深入的介绍，但是来看看如何使用这两个方法来解决一个常见的借用冲突问题：
@@ -305,7 +307,7 @@ error[E0502]: cannot borrow `*nums` as mutable because it is also borrowed as im
   |         ^^^^ mutable borrow occurs here
 ```
 
-很明显，因为同时借用了不可变与可变引用，你可以通过索引的方式来绕过:
+很明显，报错是因为同时借用了不可变与可变引用，你可以通过索引的方式来避免这个问题：
 ```rust
 fn retain_even(nums: &mut Vec<i32>) {
     let mut i = 0;
@@ -319,9 +321,9 @@ fn retain_even(nums: &mut Vec<i32>) {
 }
 ```
 
-但是这样就违背我们的初衷了，而且迭代器会让代码更加简洁，还有其它的办法吗？
+但是这样就违背我们的初衷了，毕竟迭代器会让代码更加简洁，那么还有其它的办法吗？
 
-这时就可以使用`Cell`新增的这两个方法:
+这时就可以使用 `Cell` 新增的这两个方法：
 ```rust
 use std::cell::Cell;
 
@@ -339,17 +341,17 @@ fn retain_even(nums: &mut Vec<i32>) {
 }
 ```
 
-此时代码将不会报错，因为`Cell`上的`set`方法获取的是不可变引用`pub fn set(&self, val: T)`.
+此时代码将不会报错，因为 `Cell` 上的 `set` 方法获取的是不可变引用 `pub fn set(&self, val: T)`。
 
 当然，以上代码的本质还是对 `Cell` 的运用，只不过这两个方法可以很方便的帮我们把 `&mut [T]` 类型转换成 `&[Cell<T>]` 类型。
 
 
 ## 总结
-`Cell`和`RefCell`都为我们带来了内部可变性这个重要特性，同时还将借用规则的检查从编译期推迟到运行期，但是这个检查并不能被绕过，该来早晚还是会来，`RefCell`在运行期的报错会造成`panic`
+`Cell` 和 `RefCell` 都为我们带来了内部可变性这个重要特性，同时还将借用规则的检查从编译期推迟到运行期，但是这个检查并不能被绕过，该来早晚还是会来，`RefCell` 在运行期的报错会造成 `panic`。
 
 `RefCell` 适用于编译器误报或者一个引用被在多个代码中使用、修改以至于难于管理借用关系时，还有就是需要内部可变性时。
 
 从性能上看，`RefCell` 由于是非线程安全的，因此无需保证原子性，性能虽然有一点损耗，但是依然非常好，而 `Cell` 则完全不存在任何额外的性能损耗。
 
-`Rc`跟`RefCell`结合使用可以实现多个所有者共享同一份数据，非常好用，但是潜在的性能损耗也要考虑进去，建议对于热点代码使用时，做好`benchmark`.
+`Rc` 跟 `RefCell` 结合使用可以实现多个所有者共享同一份数据，非常好用，但是潜在的性能损耗也要考虑进去，建议对于热点代码使用时，做好 `benchmark`。