写给前端开发者的 Rust 入门指南 Part 2 - 所有权

学习一门底层语言，犹如修炼内功，帮助我们以更底层的视角看待编程，写出健壮安全的代码。修炼 Rust 绝非一朝一夕，本系列文章旨在从 JavaScript 开发者的角度，对比和厘清 Rust 中那些有趣的，难啃的，或独有的概念，帮助同胞们迈出学习 Rust 的第一步。

完整文章传送门：

写给前端开发者的 Rust 入门指南 Part 1 - 内存

写给前端开发者的 Rust 入门指南 Part 2 - 所有权 📍当前位置

写给前端开发者的 Rust 入门指南 Part 3 - 借用

写给前端开发者的 Rust 入门指南 Part 4 - 生命周期

本篇登场的是 Rust 世界中的绝对主角 -- 所有权（Ownership）

一段代码，分道扬镳

看以下这段平平无奇的 JS 代码👇:

// 定义一个对象，绑定到变量 obj1 上
let obj1 = {
  a: 1,
  b: 2
};

// 把 obj1 赋值给变量 obj2
let obj2 = obj1;

// 打印以上两个值
console.log(obj1);
console.log(obj2);

即便是 JS 新手，也能一眼看出以上代码运行完毕，会打印两次 {a: 1, b: 2} 。另外，由于 obj1 是一个对象，属于引用类型数据，所以当执行 let obj2 = obj1; 这行代码时，实际上是把 obj1 的引用复制一份给了 obj2。所以，代码运行完毕后，obj1 和 obj2 指向了同一个对象 - {a: 1,b: 2}，换句话说：obj1 和 obj2 指向了同一段内存地址，且都可以访问和修改对象的数据。

同样的代码，用 Rust 来写写看：

#[derive(Debug)]
struct Obj {
  a: i32,
  b: i32
}

fn main() {
  let obj1 = Obj {a: 1, b: 2};
  let obj2 = obj1;
  println!("{:?}", obj1);
  println!("{:?}", obj2);
}

一句句分析：

首先，整段代码和前面的 JS 代码是等价的。 struct Obj {...} 声明了一个结构体（相当于 JS 中的对象），由于 Rust 是强类型的语言，定义时需要确定 Obj 中的每一个属性的类型： a 和 b 的都是 i32类型，表示都是 32 位整数；

接着，在 main 函数中：Obj {a: 1, b: 2} 创建（实例化）了这个结构体的实例 - obj1, 紧接着再把 obj1 赋值给 obj2；

最后打印 obj1 和 obj2。println! 相当于 console.log。 {:?} 表示打印字符的占位，比如我可以在打印内容前面加一些字：这是打印内容👉 {:?}。

小贴士：在 Rust 中，不是所有数据默认都能打印的，因为对于比较复杂的数据结构，Rust 并不知道你想要打印成什么样子，需要你自己实现打印方法。比如例子中的「结构体（struct）」，里面的属性可能非常复杂，所以不能直接调用 println! 。而之所以我们还是调用了，奥秘在第一行 - #[derive(Debug)]。这行奇怪的代码，紧紧贴在结构体 Obj 的上面，意思是：神龙，请给我的这个结构体默认实现一个打印功能吧。然后神龙（其实是 Rust 编译器啦😄）就会自动为这个结构体实现打印功能。这个魔法的名字叫做派生宏，后话了。

说了这么多，猜猜看，Rust 这段代码，会打印出什么呢？

答案是 -- 什么都不会打印。因为报错了，报错信息如下：

error[E0382]: borrow of moved value: `obj1`
  --> src/any.rs:11:20
   |
9  |   let obj1 = Obj {a: 1, b: 2};
   |       ---- move occurs because `obj1` has type `Obj`, which does not implement the `Copy` trait
10 |   let obj2 = obj1;
   |              ---- value moved here
11 |   println!("{:?}", obj1);
   |                    ^^^^ value borrowed here after move
   |

怎么回事？这么一段逻辑清晰且表达明确的代码，竟然会运行失败？

转移（Move）

逐步分解上例 Rust 代码到底发生了什么事情？在内存篇中我们说过，动态的，潜在占用空间大的数据，会存放在堆内存上，并且将其引用指针放在栈内存上。所以，当程序执行到 let obj1 = Obj {a: 1, b: 2}; 这一行时，内存状态是这样的：

可以看到，结构体 {a: 1, b: 2} 在堆上，obj1 是它在栈上的引用指针。

重点来了，当执行到 let obj2 = obj1; 这行代码时，Rust 在栈上复制了一份该结构体的指针（obj1 -> obj2），并把新的指针（obj2）指向结构体在堆上的地址，随后移除了旧指针(obj1)对这个结构体的访问(引用)。在这里 obj1 就地宣告死亡（很惨真的），再也访问不到堆上的结构体了。换句话说：obj1 把它对堆上数据的所有权，转移（Move）给了 obj2。

由于旧指针 obj1 访问不到堆上的数据了，因此 println!("{:?}", obj1); 这行代码就不成立了，于是 Rust 编译器报错。试图访问一个不存在的值，是导致程序崩溃的最大元凶，作为前端开发，我们永远不会忘记被 cannot read properties of undefined 这几个红色小字支配的恐惧。

知道发生了所有权转移（Move），不禁要问，为什么 Rust 有这种「诡异的」转移（Move）机制？这要从堆内存的管理说起。

堆内存的释放

内存篇曾说到：对于编程语言来说，堆内存的释放是一大难题。栈内存的释放很简单：随着程序调用栈的结束而释放，一个函数调用完毕，其作用域内的变量就得到释放。而堆上的数据就没这么简单了，JS 和 Rust 在此分道扬镳：是否允许一个堆上数据有存在多个引用对其访问/修改，JS 允许（自由的少年），Rust 不允许（沉稳的武士）。

JavaScript 的方案 - RC and GC

JS 采用的堆内存管理方案是引用计数（RC）和垃圾回收（GC）。

let obj1 = {
  a: 1,
  b: 2
};

let obj2 = obj1;

// -----至此，对象 {a: 1, b: 2} 有 2 两个引用（obj1 和 obj2)

obj2 = null
// -----至此，只剩 obj1 一个引用了 
obj1 = null
// -----至此，一个引用也没有了，准备释放内存！

以上代码中，堆内存上的 {a: 1, b: 2} 什么时候释放，取决于程序中对于它有没有引用。比如，obj1 和 obj2 都是对这个数据的引用，所以这个数据的引用数为 2。在 JS 运行时，引用计数（RC）是一个勤恳的会计，维护着每一个堆上数据的引用数，如果引用数大于零，说明这个数据是被需要的，不能释放，如果引用数归零了，说明堆上的这个数据不再被需要了，就标记一下，等待清道夫（垃圾回收）来把这一块内存释放。

以上即垃圾回收（GC）的核心原理。这套方案开箱即用，不需要程序员操心，代价是运行时需要会计（RC）和清道夫（GC）把关，养这两个员工是要付出代价的（影响性能）。而且，他们工作可能存在「疏漏」，导致内存泄漏：

let hugeObj = {...}; // 假装这是一个非常非常非常大的对象

setInterval(() => {
	console.log(hugeObj);
},1000)

以上是一个典型的 JS 内存泄漏的例子：定时器中访问了外部对象 hugeObj，而且是持续地访问（每秒一次），在这个定时器被清除之前，我们的会计（引用计数）会认为 hugeObj 永远都有用，一直被需要（真羡慕）。所以 hugeObj 自然不会被回收释放。如果我们并不需要 hugeObj 一直存在，但忘记清除定时器了，那么 hugeObj 就会一直占据着内存，占山为王，直到坐吃山空。

总结，JavaScript 允许堆上数据存在多个引用（访问/修改），在运行时靠引用计数和垃圾回收释放内存。好处是编码灵活，但牺牲了性能和内存安全。

Rust 的方案 - 所有权（Ownership）

Rust 没有垃圾回收。Rust 的内存管理基于以下两个原则：

原则1：堆上的数据，都被唯一一个栈上变量所拥有，受其控制

原则2：当栈上的变量（所有者）离开作用域，释放它拥有的堆上数据

回到这个例子中：

#[derive(Debug)]
struct Obj {
  a: i32,
  b: i32
}

fn main() {
  let obj1 = Obj {a: 1, b: 2};
  let obj2 = obj1;
  println!("{:?}", obj1);
  println!("{:?}", obj2);
}

一开始 obj1 拥有堆上结构体的数据，是这个数据的唯一拥有者,当赋值发生时（let obj2 = obj1;）, 原则1生效，即堆上数据只能有唯一一个拥有者，赋值不能像 JS 那样增加一个引用（拥有者）。因此赋值的时候，obj1 只好把堆上数据的所有权（Ownership）转移（Move）给了 obj2。至此，obj2 成为结构体数据的新主人，obj1 当场宣告死亡，在这之后的代码都禁止访问它，这也就是 println!("{:?}", obj1); 触发编译错误的原因了。

把导致错误的代码（对 obj1 的访问）去掉：

...
fn main() {
  // ---函数作用域的开始，代码开始运行----
  let obj1 = Obj {a: 1, b: 2};
  let obj2 = obj1;
  // ---函数作用域的尾部，代码运行结束了----
  // ！！！释放内存！！！
}

当 main 函数运行结束，变量 obj2 会被释放，由于它是堆上结构体的唯一拥有者，堆上的数据也在此时一并释放。符合了原则2：当栈上的变量（所有者）离开作用域，其拥有的堆上数据被释放。实际上，这段代码在编译后是这样的：

...
fn main() {
  let obj1 = Obj {a: 1, b: 2};
  let obj2 = obj1;
  // ---函数作用域的尾部，代码运行结束了，开始释放内存----
  // 编译器插入代码👇：
  drop(obj2)
}

Rust 编译器会在 main 函数的作用域底部，插入一个 drop　方法，传入 obj2。顾名思义，drop 方法把 obj2 及其拥有的堆上数据占用的内存释放了。

现在假设，如果没有转移（Move）机制，像 JS 一样，赋值时增加一个堆数据的引用指针，会发生什么呢？

...
fn main() {
  let obj1 = Obj {a: 1, b: 2};
  let obj2 = obj1; // 假设此时 obj1 和 obj2 都拥有数据的引用
  // ---这里是函数作用域的尾部，代码运行结束了，开始释放内存----
  // 编译器插入代码👇：
  drop(obj2) // 堆上数据被释放了
  drop(obj1) // error！重复释放同一块内存
}

由于 obj1 和 obj2 都拥有堆上数据的所有权（假设原则1被打破），函数运行结束后，obj1 和 obj2 都要被清除（原则2的要求），所以 Rust 编译器需要在作用域尾部插入 drop(obj2) 和 drop(obj1) 两句代码。问题来了，当 drop(obj2) 调用后，堆上这一块内存已经被释放了，紧接着调用drop(obj1)时，此时堆上的这块内存已经不属于原先那块数据了，这可能导致严重的内存安全漏洞，比如，这块内存已经分配给其他数据了，重复释放可能造成内存污染。这就是所谓的 Double Free（内存重复释放）问题。

来一个复杂一点的数据结构：

struct Point {
    x: i32,
    y: i32
}

fn main() {
  let v = vec![
    Point {x: 50, y: 50},
    Point {x: 100, y: 100},
    Point {x: 150, y: 150}
  ];
}

以上是一个嵌套结构，变量 v 拥有动态数组，动态数组里面的元素是 Point 类型，Point 是结构体，结构体拥有字段 x, y 都是 i32 整数类型。

我们发现，堆上的数据也可以被堆上数据拥有。比如动态数组存在堆上，它拥有的元素 Point 也存在堆上，Point 拥有的 i32 整数也在堆上。但最重要的是，这一切的源头 --「变量 v」是存在栈上的指针，它拥有动态数组的所有权，当变量 v 离开作用域时：

1. v 释放它拥有的堆上的动态数组
2. 动态数组释放它拥有的所有 Point 结构体
3. Point 结构体释放了它拥有的 x，y

一旦栈上变量离开作用域，数据会沿着所有权链路，如多米诺骨牌一样坍塌释放，所有权机制运转良好。

总结一下，Rust 变量的释放依赖编译器在特定的位置插入drop 方法。为了这一机制的顺利运转，Rust 让堆上数据的生命周期（分配，转移，释放）受栈上唯一所有者的控制。这就是 Rust 最独一无二的特性 -- 所有权机制（Ownership）。

没有垃圾回收机制的掣肘，Rust 具备极高的性能，只要代码符合设定好的规则，编译器就会产出内存安全、运行高效的代码。但这一切也是有代价的，基于所有权机制衍生出的各种编码规则，提高了 Rust 的理解门槛。但请相信我，迈过这个门槛，你会收获一种独一无二的编码体验。

所有权转移（Move）的场景

前面的例子中，所有权转移发生在变量的赋值传递中。其实在 Rust 中，任何使用值的场景，都可能伴随着所有权的转移。

函数的入参数和返回

fn logData(data: Vec<i32>)  {
    println!("打印成功：{:?}",data);
}

fn main() {
    let v = vec![1,2,3]; // 动态数组的所有权属于 v

    logData(v); // 所有权转移给函数的参数data，v 当场死亡
    //---------- logData 运行结束，data 内存释放，动态数组失效
    
    println!("{:?}",v); // error！访问了一个无效的引用
}

logData 函数接受参数 data -- 一个 i32 动态数组，把它打印出来。在main 函数中，一开始变量 v 拥有动态数组的所有权.调用 logData 时，传入 v，此时 v 把动态数组的所有权转移给 logData 的参数 data，变量 v 成为无效引用。随后的 println!(“{:?}”,v); 试图访问无效引用，编译器报错。

如果我希望在调用 logData 之后，能够继续访问 v 怎么办？那就把数据返回。函数的返回值也会转移数据的所有权：

// 打印 data 后，把 data 返回
fn logData(data: Vec<i32>) -> Vec<i32> {
    println!("打印成功：{:?}",data);
    data
}

fn main() {
    let v = vec![1,2,3];
    let v2 = logData(v); // 函数的return，把所有权从 data 转移给 v2
    println!("重新获取所有权 {:?}",v2); // 成功打印
}

以上代码给 logData 增加了返回值，打印后返回 data。在 Rust 中，函数的返回值不用写 return 关键字，直接把返回的值写在函数的最后，并且不加分号就好。所以最后一行的 data 相当于 return data;。另外，logData 参数申明后面的 -> Vec<i32> 表示这个函数返回值的类型是一个 i32 动态数组。函数的返回值也会发生所有权的转移，所以变量 v2 取得了动态数组的所有权，打印成功。

有没觉得这样编码很麻烦？为了避免大家对 Rust 失去耐心，有必要剧透一下，在实际编码过程中，我们其实会这样写：

fn logData(data: &Vec<i32>) {
    println!("打印成功：{:?}",data);
}

fn main() {
    let v = vec![1,2,3];
    logData(&v);
    println!("{:?}",v);
}

注意到了吗？ 参数 data 的类型是 &Vec<i32>，调用入参时，传入的是 &v。这个神奇的符号 &，叫做借用（引用）：变量 v 拥有的值，借过来给用用，所有权不用转移（Move）给我。借用（Borrowing）是基于所有权（Ownership）衍生出的另一机制。如果「所有权」是俞伯牙，那么「借用」就是钟子期，且听下回分解。

循环

循环一个集合是开发中常见的场景：

fn main() {
    let v = vec![1,2,3];
    for s in v { // 动态数组会的所有权被转移到 for 循环中去
	println!("{:?}",s);
    } // --- 循环结束后，v 无法继续使用了
    println!("{:?}", v); // error!!!
}

循环用到了 for ... in ... 语法，简直和 JS 一模一样。很好理解，把动态数组 v 中的每一个元素取出来，赋值给 s, 然后打印。既然涉及到了赋值，就会转移所有权，代码看起来像是循环把动态数组中的元素的一个个转移给 s，最后把它掏空了。实际上，只要用了这样的循环的语法，数据的所有权会被直接转移到 for 循环的语句快中，循环结束后，后续代码就无法访问 v了。值得注意的是，在 for 循环的循环体中，也是无法访问 v 的：

fn main() {
    let v = vec![1,2,3];
    for s in v { 
	println!("{:?}",s);
	println!("{:?}",v); //error! v 在循环体内无法访问
    } 
}

很合理, 动态数组正在被循环「肢解」，数据完整性未知，所以编译器阻止了访问。

对于一个这么常见的循环场景，转移所有权也太碍事了吧？不着急，大多数情况下，循环代码我们会这样写：

fn main() {
    let v = vec![1,2,3];
    for s in &v { // &v借用了数据的所有权，不发生转移
        println!("{:?}",s);
    }
    println!("{:?}", v); // 可以正常打印
}

See,神奇的借用符号 & 又出现了。&v 向 v 借用了数据所有权，所以数据在循环结束后依然能够访问。

初始化集合数据

fn main() {
    let s = String::from("Rust"); // 创建字符串
    let v = vec![s]; // s 把所有权转移给了动态数组，s 失效
    println!("{:?}",s); // error!!!
}

String::from("Rust"); 语法创建了一个字符串 - “Rust”，这个字符串是 「String 类型」, 在 Rust 中，「String 类型」和「字符串字面量」是不一样的：

// s1 和 s2 是不同的类型
let s1 = "Hello";
let s2 = String::from("Hello");

s1 是字符串字面量（&str 类型），属于 Rust 基础类型值，在编译期间大小确定，固定不变，编译后直接写入程序包中，运行时存到栈内存上，快速且高效。

s2 是 String 类型，指的是那些动态的，可变的，在编译期间无法确定大小的字符串，比如说一个表单页面，表单的值在用户输入的时候才能确定。这种情况下，我们需要一个「容器」来存放动态的字符串，这就是 String 类型。根据我们已有的知识，很容易可以推断出，String 类型的数据，储存在堆内存。

本是同根生，「字符串字面量」和「String」可以相互转换👇：

let s1 = "Hello";
let s2 = String::from("Hello");

// 字符串字面量 转 String 👇
let s1_new = s1.to_string();

// String 转 字符串字面量 👇
let s2_new = s2.as_str()

不知道你是否联想到 JS 中的 String 对象。是的，对于动态的字符串数据，JS 也会把它存在堆上。从底层视角看，很多原理是相通的。

有关 String 类型的题外话结束，回到例子中：

let s = String::from("Rust"); // 创建字符串
let v = vec![s]; // s 把所有权转移给了动态数组，s 失效
println!("{:?}",s); // error!!!

把值的引用（s），放入集合类型（vector）中作为它的初始化值，也会转移其所有权。转移之后 s 的所有权属于动态数组（vector），动态数组存在堆上，被栈上变量 v 拥有。当 v 离开作用域，释放了动态数组的内存，动态数组所拥有的 String 也会被释放。

集合数据索引取值

延续上例：

let s = String::from("Rust"); // 创建字符串
let v = vec![s]; // s 把所有权转移给了动态数组，s 失效
let first = v[0]; // cannot move out of index of `Vec<String>`

通过数组索引取值是一个及其常见的场景，但 Rust 编译器会阻止我们这么做，动态数组中的元素如果是一个堆上元素（比如本例中的 Sting），取值的过程也会伴随着所有权的转移（所有权从动态数组转移给变量 first）。如果索引取值转移了所有权，动态数组的数据完整性就无法保证了，可能造成内存安全问题，所以编译器贴心地喊停🤚。

你可能猜到了，这时候，用神奇的符号 &：

let s = String::from("Rust");
let v = vec![s];
let first = &v[0]; // 借用元素，不转移所有权
...

不转移的场景（Copy）

不知道你是否发现，开篇到现在，我们举的所有权转移（Move）的例子，全是基于堆上数据的。那栈上数据呢？比如数字、字符串字面量、布尔值...这些基础类型数据也遵循转移（Move）法则吗？

不是的，栈上数据不必遵循转移（Move）法则，直接按位复制（Bit-for-Bit Copy）。

这并不新鲜，在无论在 JS，还是 Rust 中，基础类型值（栈上数据）在传递时，都会直接按位复制一份：

let a = 1；
let b = a;

很有意思，上面这两行代码从语法上看既可以是 JS，也可以是 Rust。甚至连底层发生的事情也都一模一样：

基础类型值在赋值传递的时候，在栈上发生了按位复制。所谓按位复制，就是一个 bit 一个 bit 地完美复刻一份，新的副本和原来的毫无关系，完全独立。这从内存安全的角度看是及其安全的做法。对于静态，大小确定的值，按位复制很高效，所以他们遵循复制机制（Copy）。而诸如 vector，struct 这类复杂的动态数据，如果赋值传递也按位复制，太消耗性能，不实惠，所以他们遵循转移机制（Move），并通过「所有权机制」保障内存安全。

前文中所列举的转移场景，如果是基础类型值，就不会发生所有权转移，比如函数传参：

fn logData(data: i32)  {
    println!("打印成功：{:?}",data);
}

fn main() {
    let v = 1; 

    logData(v); // v 是基础类型，传参时自动按位复制一份给参数 data
    // -------- 函数运行结束，变量 v 依然可以访问
    
    println!("{:?}",v); // 成功打印
}

深拷贝（Clone and Copy）

有些时候，我们也需要堆上数据按位复制。比如在 JS 中，我们经常听说的「深拷贝」问题。如果想要深拷贝一个对象，可以自己实现一个方法：原理是再创建一个新的对象（新建堆内存），把原对象中的每一个属性在新对象中逐个重新创建。

在 Rust 中，某些情况可以直接调用 clone 实现深拷贝:

fn main() {
   // v 和 v1 完全独立
   let v = vec![1,2,3];
   let v1 = v.clone(); // clone 方法深拷贝了 v
   
   // s 和 s1 完全独立
   let s = String::from("Rust"); clone 方法深拷贝了 s
   Let s1 = s.clone();
   
   // 以下均可打印成功
   println!("{:?}", v);
   println!("{:?}", v1); 
   println!("{:?}", s);
   println!("{:?}", s1);
}

如上，动态数组(Vec)和 String 可以调用 clone 方法，把数据按位复制一份（在堆上），并把数据所有权交给一个栈上的变量（v1，s1）。副本和原数据相互独立，互不影响。

然而，不是所有数据类型都可以调用 clone 方法，比如结构体 struct:

struct Obj {
  a: i32,
  b: i32
}

fn main() {
   let v = Obj {a: 1, b: 2};
   let v1 = v.clone(); // 报错：no method named `clone` found for struct `Obj` in the current scope...
}

struct 默认没有 clone 方法，因为 struct 内部的数据类型可能非常复杂，如何深拷贝没有开箱即用的方法。能不能让结构体 Obj 在赋值传递的时候，也遵循 Copy 机制，自动按位复制呢？当然！Rust 是一门底层语言，我们可以精确控制数据的行为：

#[derive(Debug, Clone, Copy)] // 👈 奥秘在这里
struct Obj {
  a: i32,
  b: i32
}

fn main() {
   let v = Obj {a: 1, b: 2};
   let v1 = v;
   println!("{:?}", v); // 成功打印！！
}

请注意到第一行的 #[derive(Debug, Clone, Copy)]。在上文中，我们通过派生宏语法 -- ``#[derive(Debug)]为 Obj 实现了打印功能。现在多了两个词 --「Clone」 和 「Copy」。意思是：「万能的 Rust 编译器啊，请让 Obj 结构体具有 Clone 和 Copy 的特性，谢谢！」于是Obj 结构体的实例，就拥有了这两个特性：在本来该发生所有权转移的情况（let v1 = v;），执行了按位复制（Copy）！值得一提的是，我们只是为 Obj 这个自定义结构体实现了这些特性，其他的 struct 还是原来的样子。

你可能疑惑，我们只是想要为 Obj 实现 「Copy」 特性，为啥要捎上「Clone」呢？因为 Rust 要求，要实现 Copy，先要实现 Clone。可以想象 Copy 在内部依赖 Clone。因为实现了 Clone，所以现在也可以调用 Obj 的 clone 方法了（虽然没有必要）：

#[derive(Debug, Clone, Copy)]
struct Obj {
  a: i32,
  b: i32
}

fn main() {
   let v = Obj {a: 1, b: 2};
   let v1 = v.clone(); // clone方法按位复制
   println!("{:?}", v);
}

我们可以据此推论：**在 Rust 中，数据的各种行为，例如赋值时是否会按位复制（Copy）？是否遵循转移（Move）机制？能否调用 clone 方法？能否被打印（println）等等，这些都是 Rust 的一个个特性。Rust 默认为某些数据类型实现了某些特性，比如为 i32 整数自带 Copy 特性，所以 i32 整数在赋值传递的时候，会自动按位复制。**我们也可以手动为数据实现特性，是的，这就是 Rust 中的 trait（特征）。trait 不是本文的重点，留待后续详细分解。

共享所有权 -- Rc and Arc

想象这样一个场景：每一篇文章都有一个作者，但一个作者可以拥有很多文章。作者和文章是「一对多」的关系。用 JS 代码来表示：

// 创建 作者 类
class Author {
	constructor(name,id) {
		this.name = name;
		this.id = id
	}
}

// 创建 文章 类
class Post {
	constructor(content, author) {
		this.content = content;
		this.author = author
	}
}

// 实例化一个作者
const a1 = new Author('Lin', 1); 

// 实例化两篇文章，并关联作者
const p1 = new Post("I love Rust", a1);
const p2 = new Post("I love JS", a1);

// p1: I love Rust -- by Lin
// p2: I love JS -- by Lin
console.log(`p1: ${p1.content} -- by ${p1.author.name}`)
console.log(`p2: ${p2.content} -- by ${p2.author.name}`)

文章 p1，p2 的 author 字段，共同指向作者 a1，或者说共同「拥有」a1。这在 JS 中再正常不过了。但在 Rust 中，由于所有权机制的限制，堆上的值不允许有多个拥有者，也就意味着 p1，p2 无法共同指向 a1，那么在 Rust 中如何实现以上代码呢？

大多数情况下，Rust 在所有权机制的保护下运行良好，但某些时候，为了应对以上的类似情形，Rust 的策略是 Rc（引用计数） 和 Arc（跨线程引用计数）。与前文中介绍的 JS 的引用计数（RC）类似，Rust 也可以使用类似的引用计数功能：允许堆上的数据存在多个所有者，多个所有者共享同一个堆上内存。

Rc 和 Arc 非常类似，区别仅在于 Arc 提供了跨线程的安全机制，如果在单线程环境使用，Rc 有更好的性能。本文仅以 Rc 为例：

use std::rc::Rc; // 引入 RC

fn main() {
  let v1 = Rc::new(String::from("Rust"))；
  // --- 此刻，引用计数 = 1
  let v2 = v1.clone();
  // --- 此刻，引用计数 = 2
  let v3 = v1.clone();
  // --- 此刻，引用计数 = 3
  
  // --- 函数运行完毕，开始释放内存 ---
  // 释放 v3 成功，引用计数 = 2
  // 释放 v2 成功，引用计数 = 1
  // 释放 v1 成功，引用计数 = 0
  // 释放 v1 拥有的堆上数据（“Rust”）的内存
  // --- 成功释放，内存安全超过全国 99% 程序员，深藏功与名 ---
}

通过 use std::rc::Rc; 引入后，就可以使用 Rc 了。use 语法可以理解成 JS 中的 import，用啥就导入啥。在 main 函数块中，首先通过 Rc::new(String::from("Rust"))； 创建了一个堆上数据（Rc创建的数据都在堆上），值是 String 类型。紧接着，通过 clone 语法复制了两个指针：v2，v3。clone 方法前面介绍过，不过用在 Rc 数据上，语义就不是按位复制了，而是复制一份堆数据的指针，并把该数据的引用计数加 1。至此，v1，v2，v3 共同指向堆上数据，换句话说，他们三个共同拥有同一块内存：

Rc 虽然违背了原则1（唯一拥有者），但依然遵循原则2（堆内存随着栈上所有者离开作用域而释放），代码注解中详细标注了 main 函数生命周期全过程，Rc 数据引用计数的变化，可以看到，当函数执行完毕，每一个 Rc 引用逐个释放销毁，但引用数归零时，一切又回到所有权规则的范畴 -- 销毁那个堆内存！

虽然 v1，v2，v3 共同拥有同一块内存地址，但它们仅仅能读取数据，如果三者中任一尝试修改数据，编译器会阻止的：

use std::rc::Rc;

fn main() {
  let v1 = Rc::new(String::from("Rust"));
  let v2 = v1.clone();
  let v3 = v1.clone();

  v2.push_str("!"); // 报错：cannot borrow as mutable
}

v2 试图改变堆上的字符串，给它加上一个感叹号，但很遗憾，Rust 编译器不允许这个行为发生，因为多个指针能够修改同一个堆上数据，这个行为在 Rust 看来是极其危险的。

回到「作者与文章」的例子，我们用 Rust 实现一下(与上文中 JS 版本等价)：

use std::rc::Rc;

// 创建 作者 struct
struct Author {
    name: String,
		id: i32
}

// 创建 文章 struct
struct Post {
  content: String,
  author: Rc<Author>,
}

fn main() {
    // 实例化一个作者
    let a1 = Rc::new(Author {
        name: String::from("Lin"),
        id: 1
    });

    // 实例化两篇文章，并关联作者
    let p1 = Post {
        content: String::from("I love Rust"),
        author: a1.clone(),
    };

    let p2 = Post {
        content: String::from("I love JS"),
        author: a1.clone(),
    };

    // p1: I love Rust -- by Lin
    // p2: I love JS -- by Lin
    println!("p1: {} -- by {}", p1.content, p1.author.name);
    println!("p2: {} -- by {}", p2.content, p2.author.name);
}

Rust 的 Rc，是一种受到充分限制的引用计数机制，变量的生命周期依然在离开作用域时释放，堆上数据依然受栈上所有者的控制，且拥有者们只有数据的只读权限（当然也是有办法绕过的啦）。不知道你是否嗅到了 Rust 克制的气息，每一个特性或机制背后，都要遵循一定的条件或约定。保持克制，拥抱自由。

结语

所有权（Ownership）是 Rust 的核心机制。基于所有权，Rust 构建了一套独特的编程范式。这套范式对初学者很不友好（理解门槛高），但如果你熟练掌握了所有权及其衍生出的一系列机制（Move，Borrow...），这份独特的编码技能会给你带来从未有过的高效与自由。

下一篇，我们来说说 Rust 的借用（Borrowing）机制。