Kun

Kun

IT学徒、技术民工、斜杠青年,机器人爱好者、摄影爱好 PS、PR、LR、达芬奇潜在学习者

共 212 篇文章

链接

Kun's Blog

rust第二篇，主要讲rust中比较难理解的概念

所有权与借用

所有的程序都必须和计算机内存打交道，如何从内存中申请空间来存放程序的运行内容，如何在不需要的时候释放这些空间，成了重中之重，也是所有编程语言设计的难点之一。在计算机语言不断演变过程中，出现了三种流派：

  • 垃圾回收机制(GC)，在程序运行时不断寻找不再使用的内存，典型代表：Java、Go
  • 手动管理内存的分配和释放, 在程序中，通过函数调用的方式来申请和释放内存，典型代表：C++
  • 通过所有权来管理内存，编译器在编译时会根据一系列规则进行检查

其中 Rust 选择了第三种，最妙的是，这种检查只发生在编译期，因此对于程序运行期，不会有任何性能上的损失。

栈和堆

栈和堆是编程语言最核心的数据结构，但是在很多语言中，你并不需要深入了解栈与堆。 但对于 Rust 这样的系统编程语言，值是位于栈上还是堆上非常重要, 因为这会影响程序的行为和性能。

栈和堆的核心目标就是为程序在运行时提供可供使用的内存空间。

栈

栈按照顺序存储值并以相反顺序取出值，这也被称作后进先出。想象一下一叠盘子：当增加更多盘子时，把它们放在盘子堆的顶部，当需要盘子时，再从顶部拿走。不能从中间也不能从底部增加或拿走盘子！

增加数据叫做进栈，移出数据则叫做出栈。

因为上述的实现方式，栈中的所有数据都必须占用已知且固定大小的内存空间，假设数据大小是未知的，那么在取出数据时，你将无法取到你想要的数据。

堆

与栈不同，对于大小未知或者可能变化的数据，我们需要将它存储在堆上。

当向堆上放入数据时，需要请求一定大小的内存空间。操作系统在堆的某处找到一块足够大的空位，把它标记为已使用，并返回一个表示该位置地址的指针, 该过程被称为在堆上分配内存，有时简称为 “分配”(allocating)。

接着，该指针会被推入栈中，因为指针的大小是已知且固定的，在后续使用过程中，你将通过栈中的指针，来获取数据在堆上的实际内存位置，进而访问该数据。

由上可知，堆是一种缺乏组织的数据结构。想象一下去餐馆就座吃饭: 进入餐馆，告知服务员有几个人，然后服务员找到一个够大的空桌子（堆上分配的内存空间）并领你们过去。如果有人来迟了，他们也可以通过桌号（栈上的指针）来找到你们坐在哪。

性能区别

写入方面：入栈比在堆上分配内存要快，因为入栈时操作系统无需分配新的空间，只需要将新数据放入栈顶即可。相比之下，在堆上分配内存则需要更多的工作，这是因为操作系统必须首先找到一块足够存放数据的内存空间，接着做一些记录为下一次分配做准备。

读取方面：得益于 CPU 高速缓存，使得处理器可以减少对内存的访问，高速缓存和内存的访问速度差异在 10 倍以上！栈数据往往可以直接存储在 CPU 高速缓存中，而堆数据只能存储在内存中。访问堆上的数据比访问栈上的数据慢，因为必须先访问栈再通过栈上的指针来访问内存。

因此，处理器处理和分配在栈上数据会比在堆上的数据更加高效。

所有权与堆栈

当你的代码调用一个函数时，传递给函数的参数（包括可能指向堆上数据的指针和函数的局部变量）依次被压入栈中，当函数调用结束时，这些值将被从栈中按照相反的顺序依次移除。

因为堆上的数据缺乏组织，因此跟踪这些数据何时分配和释放是非常重要的，否则堆上的数据将产生内存泄漏 —— 这些数据将永远无法被回收。这就是 Rust 所有权系统为我们提供的强大保障。

对于其他很多编程语言，你确实无需理解堆栈的原理，但是在 Rust 中，明白堆栈的原理，对于我们理解所有权的工作原理会有很大的帮助。

C++ GC

垃圾回收器是一种动态存储分配器，它自动释放程序不再需要的已分配的块，这些块也称为垃圾。在程序员看来，垃圾就是不再被引用的对象。自动回收垃圾的过程则称为垃圾收集（garbage collection）。在一个支持垃圾收集的语言中，程序显式地申请内存，但从不需要显式的释放它们。垃圾收集器会定期识别垃圾块，并将垃圾块放回空闲链表中。显然，C语言的malloc包不是一个带GC功能的分配器，程序员显式 调用malloc分配内存，也需要显式调用free释放它。而像java、C#这些语言等则提供了垃圾收集器

垃圾回收器将存储器视为一张有向可达图。图中的节点可以分为两组：一组称为根节点，对应于不在堆中的位置，这些位置可以是寄存器、栈中的变量，或者是虚拟存储器中读写数据区域的全局变量；另外一组称为堆节点，对应于堆中一个分配块

垃圾回收的目标即是从从根集出发，寻找未被引用的堆节点，并将其释放。

垃圾回收的各种算法

引用计数算法

引用技术算法是唯一一种不用用到根集概念的GC算法。其基本思路是为每个对象加一个计数器，计数器记录的是所有指向该对象的引用数量。每次有一个新的引用指向这个对象时，计数器加一；反之，如果指向该对象的引用被置空或指向其它对象，则计数器减一。当计数器的值为0时，则自动删除这个对象。这个思路可以参考C++ 引用计数技术及智能指针的简单实现。

引用计数算法的优点是实现简单，在原生不支持GC的语言中也能容易实现出来。另一个优点这种垃圾收集机制是即时回收，也即是对象不再被引用的瞬间就立即被释放掉。而其缺点是若存在对象的循环引用，无法释放这些对象，

标记清除算法

这个算法也称为标记清除算法，为McCarthy独创。它也是目前公认的最有效的GC方案。Mark&Sweep垃圾收集器由标记阶段和回收阶段组成，标记阶段标记出根节点所有可达的对节点，清除阶段释放每个未被标记的已分配块。典型地，块头部中空闲的低位中的一位用来表示这个块是否已经被标记了。通过Mark&Sweep算法动态申请内存时，先按需分配内存，当内存不足以分配时，从寄存器或者程序栈上的引用出发，遍历上述的有向可达图并作标记（标记阶段），然后再遍历一次内存空间，把所有没有标记的对象释放（清除阶段）。因此在收集垃圾时需要中断正常程序，在程序涉及内存大、对象多的时候中断过程可能有点长。当然，收集器也可以作为一个独立线程不断地定时更新可达图和回收垃圾。该算法不像引用计数可对内存进行即时回收，但是它解决了引用计数的循环引用问题，因此有的语言把引用计数算法搭配Mark & Sweep 算法构成GC机制。

节点复制算法

Mark & Sweep算法的缺点是在分配大量对象时，且对象大都需要回收时，回收中断过程可能消耗很大。而节点复制算法则刚好相反，当需要回收的对象越多时，它的开销很小，而当大部分对象都不需要回收时，其开销反而很大。 算法的基本思路是这样的：从根节点开始，被引用的对象都会被复制到一个新的存储区域中，而剩下的对象则是不再被引用的，即为垃圾，留在原来的存储区域。释放内存时，直接把原来的存储区域释放掉，继续维护新的存储区域即可

分代回收

以上三种基本算法各有各的优缺点，也各自有许多改进的方案。通过对这三种方式的融合，出现了一些更加高级的方式。而高级GC技术中最重要的一种为分代回收。它的基本思路是这样的：程序中存在大量的这样的对象，它们被分配出来之后很快就会被释放，但如果一个对象分配后相当长的一段时间内都没有被回收，那么极有可能它的生命周期很长，尝试收集它是无用功。为了让GC变得更高效，我们应该对刚诞生不久的对象进行重点扫描，这样就可以回收大部分的垃圾。为了达到这个目的，我们需要依据对象的”年龄“进行分代，刚刚生成不久的对象划分为新生代，而存在时间长的对象划分为老生代，根据实现方式的不同，可以划分为多个代。

一种回收的实现策略可以是：首先从根开始进行一次常规扫描，扫描过程中如果遇到老生代对象则不进行递归扫描，这样可大大减少扫描次数。这个过程可使用标记清除算法或者复制收集算法。然后，把扫描后残留下来的对象划分到老生代，若是采用标记清除算法，则应该在对象上设置某个标志位标志其年龄；若是采用复制收集，则只需要把新的存储区域内对象设置为老生代就可以了。而实际的实现上，分代回收算法的方案五花八门，常常会融合几种基本算法。

C++ GC回收

C语言本身没有提供GC机制，而C++ 0x则提供了基于引用计数算法的智能指针进行内存管理。也有一些不作为C++标准的垃圾回收库，如著名的Boehm库。借助其他的算法也可以实现C/C++的GC机制，如前面所说的标记清除算法

当应用程序使用malloc试图从堆上获得内存块时，通常都是以常规方式来调用malloc，而当malloc找不到合适空闲块的时候，它就会去调用垃圾收集器，以回收垃圾到空闲链表。此时，垃圾收集器将识别出垃圾块，并通过free函数将它们返回给堆。这样看来，垃圾收集器代替我们调用了free函数，从而让我们显式分配，而无须显式释放。

上图中的垃圾收集器为一个保守的垃圾收集器。保守的定义是：每个可达的块都能够正确地被标记为可达，而一些不可达块却可能被错误地标记为可达。其根本原因在于C/C++语言不会用任何类型信息来标记存储器的位置，即对于一个整数类型来说，语言本身没有一种显式的方法来判断它是一个整数还是一个指针。因此，如果某个整数值所代表的地址恰好的某个不可达块中某个字的地址，那么这个不可达块就会被标记为可达。所以，C/C++所实现的垃圾收集器都不是精确的，存在着回收不干净的现象。而像JAVA的垃圾收集器则是精确回收。在《关于C++ 0x 里垃圾收集器的讲座》这篇文章里提到，C++标准提案中使用gcstrict、 gcrelax这样的关键字来描述一个内存区内有没有指针，但无法精确到每个数据上。实际上，早在07年，一份C++标准提案N2670就提出要将垃圾回收机制作为加入C++，最后提案是没有通过，其原因大概是因为实现复杂，由于语言本身原因存在这样那样的限制。所以在C++ 0x中除了shardptr、weakptr这些智能指针外，我们并没看看到GC机制的身影。而至于C++是如何解决引用计数的循环引用问题以及并发控制问题

rust的所有权规则

Rust中的所有权规则

  1. Rust 中每一个值都 有且只有 一个所有者(变量)
  2. 当所有者(变量)离开作用域范围时，这个值将被丢弃(drop)

所有权很强大，避免了内存的不安全性，但是也带来了一个新麻烦： 总是把一个值传来传去来使用它。 传入一个函数，很可能还要从该函数传出去，结果就是语言表达变得非常啰嗦，幸运的是，Rust 提供了新功能解决这个问题。

Rust 通过 借用(Borrowing) 这个概念来达成上述的目的，获取变量的引用，称之为借用(borrowing)。正如现实生活中，如果一个人拥有某样东西，你可以从他那里借来，当使用完毕后，也必须要物归原主。

引用与接引用

常规引用是一个指针类型，指向了对象存储的内存地址。在下面代码中，我们创建一个 i32 值的引用 y，然后使用解引用运算符来解出 y 所使用的值

fn main() {
    let x = 5;
    let y = &x;

    assert_eq!(5, x);
    // assert_eq!(5, y); 不允许比较整数与引用，因为它们是不同的类型。必须使用解引用运算符解出引用所指向的值
    assert_eq!(5, *y);
}

变量 x 存放了一个 i32 值 5。y 是 x 的一个引用。可以断言 x 等于 5。然而，如果希望对 y 的值做出断言，必须使用 *y 来解出引用所指向的值（也就是解引用）。一旦解引用了 y，就可以访问 y 所指向的整型值并可以与 5 做比较

在函数中使用也是相同，将引用作为参数传递给函数

fn main() {
    let s1 = String::from("hello");

    let len = calculate_length(&s1);

    println!("The length of '{}' is {}.", s1, len);
}

fn calculate_length(s: &String) -> usize {
    s.len()
}

calculate_length 的参数 s 类型从 String 变为 &String

& 符号即是引用，它们允许你使用值，但是不获取所有权

引用指向的值默认也是不可变的， 修改引用值需要手动加mut关键字

fn main() {
    let mut s = String::from("hello");

    change(&mut s);
}

fn change(some_string: &mut String) {
    some_string.push_str(", world");
}

可变引用同时只能存在一个

可变引用并不是随心所欲、想用就用的，它有一个很大的限制： 同一作用域，特定数据只能有一个可变引用：

let mut s = String::from("hello");

let r1 = &mut s;
let r2 = &mut s;

println!("{}, {}", r1, r2);

这种限制的好处就是使 Rust 在编译期就避免数据竞争，数据竞争可由以下行为造成：

  • 两个或更多的指针同时访问同一数据
  • 至少有一个指针被用来写入数据
  • 没有同步数据访问的机制

数据竞争会导致未定义行为，这种行为很可能超出我们的预期，难以在运行时追踪，并且难以诊断和修复。而 Rust 避免了这种情况的发生，因为它甚至不会编译存在数据竞争的代码！

很多时候，大括号可以帮我们解决一些编译不通过的问题，通过手动限制变量的作用域：

let mut s = String::from("hello");

{
    let r1 = &mut s;

} // r1 在这里离开了作用域，所以我们完全可以创建一个新的引用

let r2 = &mut s;

同一个变量的可变引用和不可变引用不能同时存在

let mut s = String::from("hello");

let r1 = &s; // 没问题
let r2 = &s; // 没问题
let r3 = &mut s; // 大问题,编译时就会报错

println!("{}, {}, and {}", r1, r2, r3);

其实这个也很好理解，正在借用不可变引用的用户，肯定不希望他借用的东西，被另外一个人莫名其妙改变了。多个不可变借用被允许是因为没有人会去试图修改数据，每个人都只读这一份数据而不做修改，因此不用担心数据被污染。

对于这种编译器优化行为，Rust 专门起了一个名字 —— Non-Lexical Lifetimes(NLL)，专门用于找到某个引用在作用域(})结束前就不再被使用的代码位置。

虽然这种借用错误有的时候会让我们很郁闷，但是你只要想想这是 Rust 提前帮你发现了潜在的 BUG，其实就开心了，虽然减慢了开发速度，但是从长期来看，大幅减少了后续开发和运维成本。

悬垂引用

悬垂引用也叫做悬垂指针，意思为指针指向某个值后，这个值被释放掉了，而指针仍然存在，其指向的内存可能不存在任何值或已被其它变量重新使用。在 Rust 中编译器可以确保引用永远也不会变成悬垂状态：当你拥有一些数据的引用，编译器可以确保数据不会在其引用之前被释放，要想释放数据，必须先停止其引用的使用。

让我们尝试创建一个悬垂引用，Rust 会抛出一个编译时错误：

fn main() {
    let reference_to_nothing = dangle();
}

fn dangle() -> &String {
    let s = String::from("hello");

    &s
}

指针

在各个编程语言中，指针的概念几乎都是相同的：指针是一个包含了内存地址的变量，该内存地址引用或者指向了另外的数据。

在 Rust 中，最常见的指针类型是引用，引用通过 & 符号表示。不同于其它语言，引用在 Rust 中被赋予了更深层次的含义，那就是：借用其它变量的值。引用本身很简单，除了指向某个值外并没有其它的功能，也不会造成性能上的额外损耗，因此是 Rust 中使用最多的指针类型。

而智能指针则不然，它虽然也号称指针，但是它是一个复杂的家伙：通过比引用更复杂的数据结构，包含比引用更多的信息，例如元数据，当前长度，最大可用长度等。总之，Rust 的智能指针并不是独创，在 C++ 或者其他语言中也存在相似的概念。

Rust 标准库中定义的那些智能指针，虽重但强，可以提供比引用更多的功能特性，例如本章将讨论的引用计数智能指针。该智能指针允许你同时拥有同一个数据的多个所有权，它会跟踪每一个所有者并进行计数，当所有的所有者都归还后，该智能指针及指向的数据将自动被清理释放。

引用和智能指针的另一个不同在于前者仅仅是借用了数据，而后者往往可以拥有它们指向的数据，然后再为其它人提供服务。

动态字符串 String 和动态数组 Vec，它们的数据结构中不仅仅包含了指向底层数据的指针，还包含了当前长度、最大长度等信息，其中 String 智能指针还提供了一种担保信息：所有的数据都是合法的 UTF-8 格式。

智能指针往往是基于结构体实现，它与我们自定义的结构体最大的区别在于它实现了 Deref 和 Drop 特征：

  • Deref 可以让智能指针像引用那样工作，这样你就可以写出同时支持智能指针和引用的代码，例如 *T
  • Drop 允许你指定智能指针超出作用域后自动执行的代码，例如做一些数据清除等收尾工作

高级语言 Python/Java 等往往会弱化堆栈的概念，但是要用好 C/C++/Rust，就必须对堆栈有深入的了解，原因是两者的内存管理方式不同：前者有 GC 垃圾回收机制，因此无需你去关心内存的细节。

栈内存从高位地址向下增长，且栈内存是连续分配的，一般来说操作系统对栈内存的大小都有限制，因此 C 语言中无法创建任意长度的数组。在 Rust 中，main 线程的栈大小是 8MB，普通线程是 2MB，在函数调用时会在其中创建一个临时栈空间，调用结束后 Rust 会让这个栈空间里的对象自动进入 Drop 流程，最后栈顶指针自动移动到上一个调用栈顶，无需程序员手动干预，因而栈内存申请和释放是非常高效的。

与栈相反，堆上内存则是从低位地址向上增长，堆内存通常只受物理内存限制，而且通常是不连续的，因此从性能的角度看，栈往往比堆更高。

栈和堆的性能

  • 小型数据，在栈上的分配性能和读取性能都要比堆上高
  • 中型数据，栈上分配性能高，但是读取性能和堆上并无区别，因为无法利用寄存器或 CPU 高速缓存，最终还是要经过一次内存寻址
  • 大型数据，只建议在堆上分配和使用

总之，栈的分配速度肯定比堆上快，但是读取速度往往取决于你的数据能不能放入寄存器或 CPU 高速缓存。 因此不要仅仅因为堆上性能不如栈这个印象，就总是优先选择栈，导致代码更复杂的实现。

由于 Box 是简单的封装，除了将值存储在堆上外，并没有其它性能上的损耗。而性能和功能往往是鱼和熊掌，因此 Box 相比其它智能指针，功能较为单一，可以在以下场景中使用它：

  • 特意的将数据分配在堆上
  • 数据较大时，又不想在转移所有权时进行数据拷贝
  • 类型的大小在编译期无法确定，但是我们又需要固定大小的类型时
  • 特征对象，用于说明对象实现了一个特征，而不是某个特定的类型

使用 Box 将数据存储在堆上

如果一个变量拥有一个数值 let a = 3，那变量 a 必然是存储在栈上的，那如果我们想要 a 的值存储在堆上就需要使用 Box<T>：

fn main() {
    let a = Box::new(3);
    println!("a = {}", a); // a = 3

    // 下面一行代码将报错
    // let b = a + 1; // cannot add `{integer}` to `Box<{integer}>`
}

这样就可以创建一个智能指针指向了存储在堆上的 3，并且 a 持有了该指针

  • println! 可以正常打印出 a 的值，是因为它隐式地调用了 Deref 对智能指针 a 进行了解引用
  • 最后一行代码 let b = a + 1 报错，是因为在表达式中，我们无法自动隐式地执行 Deref 解引用操作，你需要使用 * 操作符 let b = *a + 1，来显式的进行解引用
  • a 持有的智能指针将在作用域结束（main 函数结束）时，被释放掉，这是因为 Box<T> 实现了 Drop 特征

避免栈上数据的拷贝

当栈上数据转移所有权时，实际上是把数据拷贝了一份，最终新旧变量各自拥有不同的数据，因此所有权并未转移。

而堆上则不然，底层数据并不会被拷贝，转移所有权仅仅是复制一份栈中的指针，再将新的指针赋予新的变量，然后让拥有旧指针的变量失效，最终完成了所有权的转移

fn main() {
    // 在栈上创建一个长度为1000的数组
    let arr = [0;1000];
    // 将arr所有权转移arr1，由于 `arr` 分配在栈上，因此这里实际上是直接重新深拷贝了一份数据
    let arr1 = arr;

    // arr 和 arr1 都拥有各自的栈上数组，因此不会报错
    println!("{:?}", arr.len());
    println!("{:?}", arr1.len());

    // 在堆上创建一个长度为1000的数组，然后使用一个智能指针指向它
    let arr = Box::new([0;1000]);
    // 将堆上数组的所有权转移给 arr1，由于数据在堆上，因此仅仅拷贝了智能指针的结构体，底层数据并没有被拷贝
    // 所有权顺利转移给 arr1，arr 不再拥有所有权
    let arr1 = arr;
    println!("{:?}", arr1.len());
    // 由于 arr 不再拥有底层数组的所有权，因此下面代码将报错
    // println!("{:?}", arr.len());
}

Box 背后是调用 jemalloc 来做内存管理，所以堆上的空间无需我们的手动管理。与此类似，带 GC 的语言中的对象也是借助于 Box 概念来实现的，一切皆对象 = 一切皆 Box， 只不过我们无需自己去 Box 罢了。

Deref解引用

如果智能指针是一个结构体类型，如果你直接对它进行 *myStruct，显然编译器不知道该如何办，因此我们可以为智能指针结构体实现 Deref 特征。

实现 Deref 后的智能指针结构体，就可以像普通引用一样，通过 * 进行解引用，例如 Box<T> 智能指针：

fn main() {
    let x = Box::new(1);
    let sum = *x + 1;
}

在函数和方法中，Rust 提供了一个极其有用的隐式转换：Deref转换。简单来说，当一个实现了 Deref 特征的值被传给函数或方法时，会根据函数参数的要求，来决定使用该值原本的类型还是 Deref 后的类型，

fn main() {
    let s = String::from("hello world");
    display(&s)
}

fn display(s: &str) {
    println!("{}",s);
}

以上代码有几点值得注意：

  • String 实现了 Deref 特征，能被转换成一个 &str
  • s 是一个 String 类型，当它被传给 display 函数时，自动通过 Deref 转换成了 &str
  • 必须使用 &s 的方式来触发 Deref(仅引用类型的实参才会触发自动解引用)

Drop

在一些无 GC 语言中，程序员在一个变量无需再被使用时，需要手动释放它占用的内存资源，如果忘记了，那么就会发生内存泄漏，最终臭名昭著的 OOM 问题可能就会发生。

而在 Rust 中，你可以指定在一个变量超出作用域时，执行一段特定的代码，最终编译器将帮你自动插入这段收尾代码。这样，就无需在每一个使用该变量的地方，都写一段代码来进行收尾工作和资源释放。不禁让人感叹，Rust 的大腿真粗，香！

没错，指定这样一段收尾工作靠的就是咱这章的主角 - Drop 特征

Drop顺序：

  • 变量级别，按照逆序的方式，_x 在 _foo 之前创建，因此 _x 在 _foo 之后被 drop
  • 结构体内部，按照顺序的方式，结构体 _x 中的字段按照定义中的顺序依次 drop

对于 Drop 而言，主要有两个功能：

  • 回收内存资源
  • 执行一些收尾工作

在绝大多数情况下，我们都无需手动去 drop 以回收内存资源，因为 Rust 会自动帮我们完成这些工作，它甚至会对复杂类型的每个字段都单独的调用 drop 进行回收！但是确实有极少数情况，需要你自己来回收资源的，例如文件描述符、网络 socket 等，当这些值超出作用域不再使用时，就需要进行关闭以释放相关的资源，在这些情况下，就需要使用者自己来解决 Drop 的问题

生命周期

生命周期，简而言之就是引用的有效作用域。在大多数时候，我们无需手动的声明生命周期，因为编译器可以自动进行推导，用类型来类比下：

  • 就像编译器大部分时候可以自动推导类型 <-> 一样，编译器大多数时候也可以自动推导生命周期
  • 在多种类型存在时，编译器往往要求我们手动标明类型 <-> 当多个生命周期存在，且编译器无法推导出某个引用的生命周期时，就需要我们手动标明生命周期

Rust 生命周期之所以难，是因为这个概念对于我们来说是全新的，没有其它编程语言的经验可以借鉴。当你觉得难的时候，不用过于担心，这个难对于所有人都是平等的，多点付出就能早点解决此拦路虎，同时本书也会尽力帮助大家减少学习难度(生命周期很可能是 Rust 中最难的部分)。

生命周期的主要作用是避免悬垂引用，它会导致程序引用了本不该引用的数据

{
    let r;

    {
        let x = 5;
        r = &x;
    }

    println!("r: {}", r);
}

此处 r 就是一个悬垂指针，它引用了提前被释放的变量 x，r 引用了内部花括号中的 x 变量，但是 x 会在内部花括号 } 处被释放，因此回到外部花括号后，r 会引用一个无效的 x

可以将上面的代码进行修改

{
    let x = 5;            // ----------+-- 'b
                          //           |
    let r = &x;           // --+-- 'a  |
                          //   |       |
    println!("r: {}", r); //   |       |
                          // --+       |
}                         // ----------+

根据之前的结论，我们重新实现了代码，现在 x 的生命周期 'b 大于 r 的生命周期 'a，因此 r 对 x 的引用是安全的。

在存在多个引用时，编译器有时会无法自动推导生命周期，此时就需要我们手动去标注，通过为参数标注合适的生命周期来帮助编译器进行借用检查的分析

生命周期的语法也颇为与众不同，以 ' 开头，名称往往是一个单独的小写字母，大多数人都用 'a 来作为生命周期的名称。 如果是引用类型的参数，那么生命周期会位于引用符号 & 之后，并用一个空格来将生命周期和引用参数分隔开

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

生命周期语法用来将函数的多个引用参数和返回值的作用域关联到一起，一旦关联到一起后，Rust 就拥有充分的信息来确保我们的操作是内存安全的。

编译器的生命周期消除规则：

在使用过程中，很多时候无需标注生命周期，编译器为了简化用户的使用，运用了生命周期消除大法

编译器使用三条消除规则来确定哪些场景不需要显式地去标注生命周期。其中第一条规则应用在输入生命周期上，第二、三条应用在输出生命周期上。若编译器发现三条规则都不适用时，就会报错，提示你需要手动标注生命周期。

  1. 每一个引用参数都会获得独自的生命周期

    例如一个引用参数的函数就有一个生命周期标注: fn foo<'a>(x: &'a i32)，两个引用参数的有两个生命周期标注:fn foo<'a, 'b>(x: &'a i32, y: &'b i32), 依此类推。

  2. 若只有一个输入生命周期(函数参数中只有一个引用类型)，那么该生命周期会被赋给所有的输出生命周期，也就是所有返回值的生命周期都等于该输入生命周期

    例如函数 fn foo(x: &i32) -> &i32，x 参数的生命周期会被自动赋给返回值 &i32，因此该函数等同于 fn foo<'a>(x: &'a i32) -> &'a i32

  3. 若存在多个输入生命周期，且其中一个是 &self 或 &mut self，则 &self 的生命周期被赋给所有的输出生命周期

    拥有 &self 形式的参数，说明该函数是一个 方法，该规则让方法的使用便利度大幅提升。

在 Rust 中有一个非常特殊的生命周期，那就是 'static，拥有该生命周期的引用可以和整个程序活得一样久。

无界生命周期

不安全代码(unsafe)经常会凭空产生引用或生命周期，这些生命周期被称为是 无界(unbound) 的。

无界生命周期往往是在解引用一个裸指针(裸指针 raw pointer)时产生的，换句话说，它是凭空产生的，因为输入参数根本就没有这个生命周期

fn f<'a, T>(x: *const T) -> &'a T {
    unsafe {
        &*x
    }
}

上述代码中，参数 x 是一个裸指针，它并没有任何生命周期，然后通过 unsafe 操作后，它被进行了解引用，变成了一个 Rust 的标准引用类型，该类型必须要有生命周期，也就是 'a。

可以看出 'a 是凭空产生的，因此它是无界生命周期。这种生命周期由于没有受到任何约束，因此它想要多大就多大，这实际上比 'static 要强大。例如 &'static &'a T 是无效类型，但是无界生命周期 &'unbounded &'a T 会被视为 &'a &'a T 从而通过编译检查，因为它可大可小，就像孙猴子的金箍棒一般。

我们在实际应用中，要尽量避免这种无界生命周期。最简单的避免无界生命周期的方式就是在函数声明中运用生命周期消除规则。若一个输出生命周期被消除了，那么必定因为有一个输入生命周期与之对应。

生命周期约束 HRTB

生命周期约束跟特征约束类似，都是通过形如 'a: 'b 的语法，来说明两个生命周期的长短关系

假设有两个引用 &'a i32 和 &'b i32，它们的生命周期分别是 'a 和 'b，若 'a >= 'b，则可以定义 'a:'b，表示 'a 至少要活得跟 'b 一样久

struct DoubleRef<'a,'b:'a, T> {
    r: &'a T,
    s: &'b T
}

闭包、迭代器

泛型

我们在编程中，经常有这样的需求：用同一功能的函数处理不同类型的数据，例如两个数的加法，无论是整数还是浮点数，甚至是自定义类型，都能进行支持。在不支持泛型的编程语言中，通常需要为每一种类型编写一个函数

多态

多态是相对于class而言的，就像函数重载对于函数来说。

在编程的时候，我们经常利用多态。通俗的讲，多态就是好比坦克的炮管，既可以发射普通弹药，也可以发射制导炮弹（导弹），也可以发射贫铀穿甲弹，甚至发射子母弹，没有必要为每一种炮弹都在坦克上分别安装一个专用炮管，即使生产商愿意，炮手也不愿意，累死人啊。所以在编程开发中，我们也需要这样“通用的炮管”，这个“通用的炮管”就是多态。

实际上，泛型就是一种多态。泛型主要目的是为程序员提供编程的便利，减少代码的臃肿，同时可以极大地丰富语言本身的表达能力，为程序员提供了一个合适的炮管。想想，一个函数，可以代替几十个，甚至数百个函数，是一件多么让人兴奋的事情：

使用泛型参数，有一个先决条件，必需在使用前对其进行声明

fn largest<T>(list: &[T]) -> T {
    let mut largest = list[0];

    for &item in list.iter() {
        if item > largest {
            largest = item;
        }
    }

    largest
}

首先 largest<T> 对泛型参数 T 进行了声明，然后才在函数参数中进行使用该泛型参数 list: &[T] ,最后，该函数返回值的类型也是 T。

结构体中的字段类型也可以用泛型来定义

struct Point<T> {
    x: T,
    y: T,
}

struct Point1<T,U> {
    x: T,
    y: U,
}

fn main() {
    let integer = Point { x: 5, y: 10 };
    let float = Point { x: 1.0, y: 4.0 };
}

提前声明，跟泛型函数定义类似，首先我们在使用泛型参数之前必需要进行声明 Point<T>，接着就可以在结构体的字段类型中使用 T 来替代具体的类型

枚举中使用泛型

方法中使用泛型

const泛型

const 泛型，也就是针对值的泛型，可以用于处理数组长度的问题

fn display_array<T: std::fmt::Debug, const N: usize>(arr: [T; N]) {
    println!("{:?}", arr);
}
fn main() {
    let arr: [i32; 3] = [1, 2, 3];
    display_array(arr);

    let arr: [i32; 2] = [1, 2];
    display_array(arr);
}

如上所示，我们定义了一个类型为 [T; N] 的数组，其中 T 是一个基于类型的泛型参数，这个和之前讲的泛型没有区别，而重点在于 N 这个泛型参数，它是一个基于值的泛型参数！因为它用来替代的是数组的长度。

N 就是 const 泛型，定义的语法是 const N: usize，表示 const 泛型 N ，它基于的值类型是 usize。

在泛型参数之前，Rust 完全不适合复杂矩阵的运算，自从有了 const 泛型，一切即将改变。

泛型的性能

在 Rust 中泛型是零成本的抽象，意味着你在使用泛型时，完全不用担心性能上的问题。

但是任何选择都是权衡得失的，既然我们获得了性能上的巨大优势，那么又失去了什么呢？Rust 是在编译期为泛型对应的多个类型，生成各自的代码，因此损失了编译速度和增大了最终生成文件的大小。

Rust 通过在编译时进行泛型代码的 单态化(monomorphization)来保证效率。单态化是一个通过填充编译时使用的具体类型，将通用代码转换为特定代码的过程。

编译器所做的工作正好与我们创建泛型函数的步骤相反，编译器寻找所有泛型代码被调用的位置并针对具体类型生成代码。

我们可以使用泛型来编写不重复的代码，而 Rust 将会为每一个实例编译其特定类型的代码。这意味着在使用泛型时没有运行时开销；当代码运行，它的执行效率就跟好像手写每个具体定义的重复代码一样。这个单态化过程正是 Rust 泛型在运行时极其高效的原因。

let integer = Some(5);
let float = Some(5.0);

// 编译代码
// enum Option_i32 {
//     Some(i32),
//     None,
// }

// enum Option_f64 {
//     Some(f64),
//     None,
// }

// fn main() {
//     let integer = Option_i32::Some(5);
//     let float = Option_f64::Some(5.0);
// }

特征

把一些类中的行为抽象出来，就要使用 Rust 中的特征 trait 概念。可能你是第一次听说这个名词，但是不要怕，如果学过其他语言，那么大概率你听说过接口，没错，特征很类似接口。

特征定义了一个可以被共享的行为，只要实现了特征，你就能使用该行为。

例如，我们现在有文章 Post 和微博 Weibo 两种内容载体，而我们想对相应的内容进行总结，也就是无论是文章内容，还是微博内容，都可以在某个时间点进行总结，那么总结这个行为就是共享的，因此可以用特征来定义：

pub trait Summary {
    fn summarize(&self) -> String;
}

使用 trait 关键字来声明一个特征，Summary 是特征名。在大括号中定义了该特征的所有方法，在这个例子中是： fn summarize(&self) -> String。

特征只定义行为看起来是什么样的，而不定义行为具体是怎么样的。因此，我们只定义特征方法的签名，而不进行实现，此时方法签名结尾是 ;，而不是一个 {}。

特征只定义行为看起来是什么样的，因此我们需要为类型实现具体的特征，定义行为具体是怎么样的。

可以为 Post 和 Weibo 实现 Summary 特征：

pub trait Summary {
    fn summarize(&self) -> String;
}
pub struct Post {
    pub title: String, // 标题
    pub author: String, // 作者
    pub content: String, // 内容
}

impl Summary for Post {
    fn summarize(&self) -> String {
        format!("文章{}, 作者是{}", self.title, self.author)
    }
}

pub struct Weibo {
    pub username: String,
    pub content: String
}

impl Summary for Weibo {
    fn summarize(&self) -> String {
        format!("{}发表了微博{}", self.username, self.content)
    }
}

Rust 引入了一个概念 —— 特征对象。

在动态类型语言中，有一个很重要的概念：鸭子类型(duck typing)，简单来说，就是只关心值长啥样，而不关心它实际是什么。当一个东西走起来像鸭子，叫起来像鸭子，那么它就是一只鸭子，就算它实际上是一个奥特曼，也不重要，我们就当它是鸭子。

使用特征对象和 Rust 类型系统来进行类似鸭子类型操作的优势是，无需在运行时检查一个值是否实现了特定方法或者担心在调用时因为值没有实现方法而产生错误。如果值没有实现特征对象所需的特征， 那么 Rust 根本就不会编译这些代码

泛型是在编译期完成处理的：编译器会为每一个泛型参数对应的具体类型生成一份代码，这种方式是静态分发(static dispatch)，因为是在编译期完成的，对于运行期性能完全没有任何影响。

与静态分发相对应的是动态分发(dynamic dispatch)，在这种情况下，直到运行时，才能确定需要调用什么方法。之前代码中的关键字 dyn 正是在强调这一“动态”的特点。

当使用特征对象时，Rust 必须使用动态分发。编译器无法知晓所有可能用于特征对象代码的类型，所以它也不知道应该调用哪个类型的哪个方法实现。为此，Rust 在运行时使用特征对象中的指针来知晓需要调用哪个方法。动态分发也阻止编译器有选择的内联方法代码，这会相应的禁用一些优化。

循环引用

Rust 的安全性是众所周知的，但是不代表它不会内存泄漏。一个典型的例子就是同时使用 Rc<T> 和 RefCell<T> 创建循环引用，最终这些引用的计数都无法被归零，因此 Rc<T> 拥有的值也不会被释放清理。

当你使用 RefCell<Rc<T>> 或者类似的类型嵌套组合（具备内部可变性和引用计数）时，就要打起万分精神，前面可能是深渊！

Weak 非常类似于 Rc，但是与 Rc 持有所有权不同，Weak 不持有所有权，它仅仅保存一份指向数据的弱引用：如果你想要访问数据，需要通过 Weak 指针的 upgrade 方法实现，该方法返回一个类型为 Option<Rc<T>> 的值。

弱引用就是不保证引用关系依然存在，如果不存在，就返回一个 None！

因为 Weak 引用不计入所有权，因此它无法阻止所引用的内存值被释放掉，而且 Weak 本身不对值的存在性做任何担保，引用的值还存在就返回 Some，不存在就返回 None。

比较一下Weak与Rc

Weak Rc
不计数 引用计数
不拥有所有权 拥有值的所有权
不阻止值被释放(drop) 所有权计数归零，才能 drop
引用的值存在返回 Some，不存在返回 None 引用的值必定存在
通过 upgrade 取到 Option<Rc<T>>，然后再取值 通过 Deref 自动解引用，取值无需任何操作

通过这个对比，可以非常清晰的看出 Weak 为何这么弱，而这种弱恰恰非常适合我们实现以下的场景：

  • 持有一个 Rc 对象的临时引用，并且不在乎引用的值是否依然存在
  • 阻止 Rc 导致的循环引用，因为 Rc 的所有权机制，会导致多个 Rc 都无法计数归零

使用方式简单总结下：对于父子引用关系，可以让父节点通过 Rc 来引用子节点，然后让子节点通过 Weak 来引用父节点。

Weak 通过 use std::rc::Weak 来引入，它具有以下特点:

  • 可访问，但没有所有权，不增加引用计数，因此不会影响被引用值的释放回收
  • 可由 Rc<T> 调用 downgrade 方法转换成 Weak<T>
  • Weak<T> 可使用 upgrade 方法转换成 Option<Rc<T>>，如果资源已经被释放，则 Option 的值是 None
  • 常用于解决循环引用的问题

也可以使用 unsafe 里的裸指针来解决循环引用的问题

unsafe 不安全，但是在各种库的代码中依然很常见用它来实现自引用结构，主要优点如下:

  • 性能高，毕竟直接用裸指针操作
  • 代码更简单更符合直觉: 对比下 Option<Rc<RefCell<Node>>>

全局变量

在一些场景，我们可能需要全局变量来简化状态共享的代码，包括全局 ID，全局数据存储等等

首先，有一点可以肯定，全局变量的生命周期肯定是'static，但是不代表它需要用static来声明，例如常量、字符串字面值等无需使用static进行声明，原因是它们已经被打包到二进制可执行文件中。

我们大多数使用的全局变量都只需要在编译期初始化即可，例如静态配置、计数器、状态值等等。

编译时初始化的全局变量

静态常量

全局常量可以在程序任何一部分使用，当然，如果它是定义在某个模块中，你需要引入对应的模块才能使用。常量，顾名思义它是不可变的，很适合用作静态配置

const MAX_ID: usize =  usize::MAX / 2;
fn main() {
   println!("用户ID允许的最大值是{}",MAX_ID);
}

常量与普通变量的区别

  • 关键字是const而不是let
  • 定义常量必须指明类型（如 i32）不能省略
  • 定义常量时变量的命名规则一般是全部大写
  • 常量可以在任意作用域进行定义，其生命周期贯穿整个程序的生命周期。编译时编译器会尽可能将其内联到代码中，所以在不同地方对同一常量的引用并不能保证引用到相同的内存地址
  • 常量的赋值只能是常量表达式/数学表达式，也就是说必须是在编译期就能计算出的值，如果需要在运行时才能得出结果的值比如函数，则不能赋值给常量表达式
  • 对于变量出现重复的定义(绑定)会发生变量遮盖，后面定义的变量会遮住前面定义的变量，常量则不允许出现重复的定义

静态变量

静态变量允许声明一个全局的变量，常用于全局数据统计，例如我们希望用一个变量来统计程序当前的总请求数：

static mut REQUEST_RECV: usize = 0;
fn main() {
   unsafe {
        REQUEST_RECV += 1;
        assert_eq!(REQUEST_RECV, 1);
   }
}

Rust 要求必须使用unsafe语句块才能访问和修改static变量，因为这种使用方式往往并不安全，其实编译器是对的，当在多线程中同时去修改时，会不可避免的遇到脏数据。

只有在同一线程内或者不在乎数据的准确性时，才应该使用全局静态变量。

和常量相同，定义静态变量的时候必须赋值为在编译期就可以计算出的值(常量表达式/数学表达式)，不能是运行时才能计算出的值(如函数)

静态变量和常量的区别

  • 静态变量不会被内联，在整个程序中，静态变量只有一个实例，所有的引用都会指向同一个地址
  • 存储在静态变量中的值必须要实现 Sync trait

原子类型

想要全局计数器、状态控制等功能，又想要线程安全的实现，原子类型是非常好的办法。

use std::sync::atomic::{AtomicUsize, Ordering};
static REQUEST_RECV: AtomicUsize  = AtomicUsize::new(0);
fn main() {
    for _ in 0..100 {
        REQUEST_RECV.fetch_add(1, Ordering::Relaxed);
    }

    println!("当前用户请求数{:?}",REQUEST_RECV);
}

运行时初始化的全局变量

lazy_static是社区提供的非常强大的宏，用于懒初始化静态变量，之前的静态变量都是在编译器初始化的，因此无法使用函数调用进行赋值，而lazy_static允许我们在运行期初始化静态变量！

use std::sync::Mutex;
use lazy_static::lazy_static;
lazy_static! {
    static ref names: Mutex<String> = Mutex::new(String::from("Sunface, Jack, Allen"));
}

fn main() {
    let mut v = names.lock().unwrap();
    v.push_str(", Myth");
    println!("{}",v);
}

当然，使用lazy_static在每次访问静态变量时，会有轻微的性能损失，因为其内部实现用了一个底层的并发原语std::sync::Once，在每次访问该变量时，程序都会执行一次原子指令用于确认静态变量的初始化是否完成。

lazy_static宏，匹配的是static ref，所以定义的静态变量都是不可变引用

Rust为我们提供了Box::leak方法，它可以将一个变量从内存中泄漏(听上去怪怪的，竟然做主动内存泄漏)，然后将其变为'static生命周期，最终该变量将和程序活得一样久，因此可以赋值给全局静态变量config。

use std::sync::Mutex;

#[derive(Debug)]
struct Config {
    a: String,
    b: String
}
static mut config: Option<&mut Config> = None;

fn main() {
    let c = Box::new(Config {
        a: "A".to_string(),
        b: "B".to_string(),
    });

    unsafe {
        // 将`c`从内存中泄漏，变成`'static`生命周期
        config = Some(Box::leak(c));
        println!("{:?}", config);
    }
}

宏编程

C 语言中的宏是非常危险的东东，但并不是所有语言都像 C 这样，例如对于古老的语言 Lisp 来说，宏就是就是一个非常强大的好帮手

println! 就是一个最常用的宏，可以看到它和函数最大的区别是：它在调用时多了一个 !，除此之外还有 vec! 、assert_eq! 都是相当常用的，可以说宏在 Rust 中无处不在。

println! 后面跟着的是 ()，而 vec! 后面跟着的是 []，这是因为宏的参数可以使用 ()、[] 以及 {}:

fn main() {
    println!("aaaa");
    println!["aaaa"];
    println!{"aaaa"}
}

虽然三种使用形式皆可，但是 Rust 内置的宏都有自己约定俗成的使用方式，例如 vec![...]、assert_eq!(...) 等。

在 Rust 中宏分为两大类：声明式宏( *declarative macros* ) macro_rules! 和三种过程宏( *procedural macros* ):

  • #[derive]，在之前多次见到的派生宏，可以为目标结构体或枚举派生指定的代码，例如 Debug 特征
  • 类属性宏(Attribute-like macro)，用于为目标添加自定义的属性
  • 类函数宏(Function-like macro)，看上去就像是函数调用

宏与函数的区别

宏和函数的区别并不少，而且对于宏擅长的领域，函数其实是有些无能为力的。

元编程

从根本上来说，宏是通过一种代码来生成另一种代码，如果大家熟悉元编程，就会发现两者的共同点。

在附录 D中讲到的 derive 属性，就会自动为结构体派生出相应特征所需的代码，例如 #[derive(Debug)]，还有熟悉的 println! 和 vec!，所有的这些宏都会展开成相应的代码，且很可能是长得多的代码。

总之，元编程可以帮我们减少所需编写的代码，也可以一定程度上减少维护的成本，虽然函数复用也有类似的作用，但是宏依然拥有自己独特的优势。

可变参数

Rust 的函数签名是固定的：定义了两个参数，就必须传入两个参数，多一个少一个都不行，对于从 JS/TS 过来的同学，这一点其实是有些恼人的。

而宏就可以拥有可变数量的参数，例如可以调用一个参数的 println!("hello")，也可以调用两个参数的 println!("hello {}", name)。

宏展开

由于宏会被展开成其它代码，且这个展开过程是发生在编译器对代码进行解释之前。因此，宏可以为指定的类型实现某个特征：先将宏展开成实现特征的代码后，再被编译。

而函数就做不到这一点，因为它直到运行时才能被调用，而特征需要在编译期被实现。

宏的缺点

相对函数来说，由于宏是基于代码再展开成代码，因此实现相比函数来说会更加复杂，再加上宏的语法更为复杂，最终导致定义宏的代码相当地难读，也难以理解和维护。

如果你觉得我的文章对你有帮助的话，希望可以推荐和交流一下。欢迎關注和 Star 本博客或者关注我的 Github。