Ownership, Borrowing 与 Lifetime 共同成就了 rust 中的内存安全，也是 rust 语言中最精髓的创造，我们就来学习学习它们究竟是什么，为什么要引入这些概念。

权力与风险共生

权力与风险往往是一同出现。如果你被授予了制作核弹的权力，那么在你制造它时其实是面临着诸多的风险。

早期的编程语言如 C/C++ 赋予了程序员极高的权力，它们能自由地操作计算机的内存（虚拟内存），程序员们因此可以尽情地挥洒着自己的创造力来达到更强大的性能。

然而这份权力也带来了许多风险，例如一个常见的问题是内存泄漏，即忘记 free 自己 malloc 出来的内存，程序不断运行最终导致内存耗尽，C++ 通过引入析构函数防止程序员忘记释放内存。但另一个常见问题依旧无法避免，即访问已经释放的内存，或者尝试释放已经释放的内存。

人们认识到，内存管理存在的风险已经远远大于它所赋予的权力带来的好处，Java 语言的便通过引入 GC （垃圾回收器）替程序员管理内存。程序员不再需要关心什么时候释放内存，因为 JVM 会自动处理；也不必害怕会访问已经释放的内存，因为只要内存还有变量使用，JVM 就不会去释放它。而对应的，GC 剥夺了程序员自由操作内存的权力，付出的代价便是额外的性能开销。

什么是内存安全

让我们举个例子：

void example() {
    vector<string> vector;
    ...

    auto& elem = vector[0];
    vector.push_back(some_string);
    cout << elem;
}

我们知道，vector 内部保存着一个数组，当 push_back 被调用时，它会查看该数组还有多少剩余空间，若空间不足，则会开辟新的空间，并将原数组的内容拷贝，如：

// this code might not compile, but you got the idea.
void push_back(string elem) {
    if (this.size == this.capacity) {
        string* new_data = new string[this.capacity * 2];
        memcpy(new_data, this.data, this.size * sizeof(string*));

        delete[] this.data;  // the old array is free

        this.data = data;
    }

    this.data[this.size++] = elem;
}

即在执行 vector.push_back 时，elem 指向的内存已经被释放了，造成了“访问已释放内存”的问题。也许程序不会直接崩溃，但极可能得到的错误的结果。

上面的例子中，产生“内存安全”的原因是同时达成了两个因素：

  1. 存在别名。即不同的变量（elem 和 vector）指向了同一块内存区域。
  2. 存在修改。即 push_back 过程中 delete 了该内存。

Ownership 及 Borrowing

Rust 提出了 Ownership（所有权）及 Borrowing（租借）的概念，做了如下限制：

  1. 所有的资源只能有一个主人（owner）。
  2. 其它人可以租借这个资源。
  3. 但当这个资源被借走时，主人不允许释放或修改该资源。

可以看到，这 3 条规则的目的是防止“存在别名”和“存在修改”同时发生。一个资源如果被共享了，则不允许修改；如果想修改资源，则不允许共享。

想象有一本书（资源），则依照上述 3 个准则，有：

1. 它只有一个主人。当然你可以把书“给”其它人，所有权就归其它人。

fn main() {
    let a = String::from("book"); // "book" 归 a 所有
    let b = a;                    // a 将 "book" 转让给 b
    println!("a = {}", a);        // 出错，a 已经无权使用资源
}

2. 允许租借。你可以先把书“给”别人，别人用完后再“给”你。但 rust 中的“借”，则保证了对方不会不把书还你。例如：

pub fn main() {
    let a = String::from("book");
    {
        let b = a;            // a 将 "book" 转让给 b
    }                         // b 死了，却没有将 "book" 还给 a
    println!("a = '{}'", a);  // 出错，"book" 不在 a 手上。
}

你可以将书借给多个人（想象几个人一起看书），前提是它们只想“读”这本书，即 rust 允许有多个不可变的引用 (&T)：

pub fn main() {
    let mut a = String::from("book");
    let b = &a;       // "book" 借给 b 只读
    let c = &a;       // "book" 同时 借给 c 只读
    println!("a = '{}'", a);
    println!("b = '{}'", b);
    println!("b = '{}'", c);
}

如果有一个人将书借去“写”，则不允许其它人同时“读”，即 rust 只允许有一个可变的引用(&mut T)：

pub fn main() {
    let mut a = String::from("book");
    let b = &mut a;       // "book" 借给 b 写
    let c = &a;           // 错误，有人借书“写”时，不允许借来“读”
}

3. 如果有人还借着书（无论读写），不允许主人修改或销毁书。

pub fn main() {
    let b;
    {
        let a = String::from("book");
        b = &a;         // "book" 借给 b
    }                   // 错误，a 死亡，需要销毁书，但 b 还借着书
}

最后，当拥有者死亡时，rust 会销毁它拥有的资源，由于一份资源只有一个拥有者，因此并不会造成销毁多次的情况。

这三条规则一起，保证了“存在别名”和“存在修改”不会同时发生，最终保证了内存安全，同时防止了多线程的数据竞争。

Lifetime

我们再回顾上节关于 Ownership 的三条规则，以便分析：

  1. 所有的资源只能有一个主人（owner）。
  2. 其它人可以租借这个资源。
    1. 同时可以有多个不可变引用(&T)。
    2. 同时只可以有一个可变引用(&mut T)。
  3. 但当这个资源被借走时，主人不允许释放或修改该资源。

rust 需要在编译期间就要保证我们的代码不会违反上面三条限制，这样做最大的优点就是不需要 runtime ，也就是不会增加额外的运行时开销。那么编译器又是如何通过静态分析来保证上述限制呢？

一个很直接的想法（不代表实际实现）是：为每个变量维护一个集合，集合里记录该变量的引用（Reference，也就是租借），那么编译器在分析时就能确保规则 #1, #2.1, #2.2。而为了确保规则 #3，rust 编译器需要确保一个资源的 reference 的存在时间小于比资源的 Owner 的存在时间。

Lifetime （生命周期）是 rust 编译器用于对比资源 owner 的存在时间与资源 reference 的存在时间的工具。Lifetime 可以理解为变量的作用域，例如：

pub fn main() {
    let mut a = String::from("book");
    let x = &a;
    a.push('A');    // 违反 #3 存在 a 的引用，不允许修改
}

上例中，

            {    a    x    *    }
所有者 a:        |______________|
借用者 x:             |_________|   x = &a
  修改 a:                  |        失败：存在 a 的引用 x 违反 #3

而下例中

pub fn main() {
    let mut a = String::from("book");
    {
        let x = &a;
    }                // x 作用域结束
    a.push('A');     // 成功：所有对 a  的引用已经结束
}

对应是作用域为：

            {    a    {    x    }    *    }
所有者 a:        |________________________|
借用者 x:                  |____|            x = &a
  修改 a:                            |       成功：对 a 的引用已经结束

可以看到，通过对作用域的分析，rust 编译器就能够保证资源的 owner 存活时间比资源的引用更长。

人为标注生命周期

上面的例子较为简单，编译器可以做一些自动的分析来判断代码是否佥，但还有一些情况下，编译器并没有办法知道生命周期的是否合法，如：

fn foo(x: &str, y: &str) -> &str {
    if random() % 2 == 0 { x } else { y }
}

fn main() {
    let x = String::from("X");
    let z;
    {
        let y = String::from("Y");
        z = foo(&x, &y);
    }                       // ①
    println!("z = {}", z);
}

上述例子中，如果 foo 返回了 x 的值，由于变量 z 生命周期小于 x 因此不会产生内存安全问题；但当 foo 返回 y 时，①处 y 作用域结束，但 z 依旧持有 y 的引用，因此存在内存安全问题。

这里的问题是单凭静态分析本身并没有办法确定所有的生命周期，因此需要一定的人工介入，人为地给编译器一些提示：

fn foo<'a>(x: &'a str, y: &'a str) -> &'a str {
    if random() % 2 == 0 { x } else { y }
}

上述标识的含义是，函数 foo 的返回值的生命周期，要小于任意参数的生命周期。有了这个提示，编译器就很容易知道下例中的代码违反了这个约定。

pub fn main() {
    let x = String::from("X");
    let z;
    let y = String::from("Y");
    z = foo(&x, &y);
    println!("z = {}", z);
}

给出作用域如下：

     {    x    z    y     *    }
x:        |____________________|
z:             |_______________|
y:                  |__________|
foo 的要求： Lifetime(z) <= Lifetime(x) & Lifetime(y) // 不成立

作用域作为生命周期的不足

上小节的例子说明了为什么 rust 需要引入 Lifetime 的概念，以及为什么在一些情况下需要人为指定 Lifetime。只是使用变量的作用域作为生命周期会有“误判”，即某些并没有违反规则 #3 的情形也会被 rust 认为是非法的。例如：

pub fn main() {
    let mut a = String::from("book1");
    let mut b = String::from("book2");
    let mut c = &mut a;
    c = &mut b;
    a.push('C');  // ① rust 报错：已存在对 a 的可变引用
}

上述代码中，rust 认为①处存在对变量 a 的引用，原因是变量 c 是对 a 的引用，并且在 ①处 c 的作用域还未结束，因此认为依旧存在对 a 的引用。但实际上 c 对 a 的引用已经结束。这也是直接用作用域作为生命周期的不足，在 rust 中可以通过如下方案绕过：

pub fn main() {
    let mut a = String::from("book1");
    let mut b = String::from("book2");
    {
        let mut c = &mut a;
        c = &mut b;
    }
    a.push('C');
}

如何指定 Lifetime

虽然理论上，我们可以指定各种复杂的 Lifetime 规则，但由于我们指定的规则是作用在编译期的静态分析，所以我们指定的规则有一定的要求，具体如下：

fn foo<'X, 'Y, 'Z>(x: &'X str, x: &'Y str, x: &'Z str) -> &'R str {
    ...
}

Lifetime 推导公式 ： 当输出值 R 依赖输入值 X Y Z …，当且仅当输出值的 Lifetime 为所有输入值的 Lifetime 交集的子集时，生命周期合法。

Lifetime(R) ⊆ ( Lifetime(X) ∩ Lifetime(Y) ∩ Lifetime(Z) ∩ Lifetime(...) )

因此，下例中指定的 Lifetime 是非法的。

fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
    if true { x } else { y }
}

因为

Lifetime(返回值) ⊆ ( Lifetime(x) ∩ Lifetime(y) )

即：

'a ⊆ ('a ∩ 'b)  // 'b 可能小于 'a ，因此不总是成立

上面的规则本质上就是要求函数返回值的 Lifetime 要小于任意一个参数的 Lifetime。为什么需要这样的规则呢？我们重用上节用到的一个例子，如下：

fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
    if random() % 2 == 0 { x } else { y }
}

// 下面的代码编译不过，用来演示如果没有 lifetime 分析可能造成的“不安全”
fn main() {
    let x = String::from("X");
    let z;
    {
        let y = String::from("Y");
        z = foo(&x, &y);  // ①
    }
    println!("z = {}", z);
}

由于 rust 做的是静态分析，因此在 ① 处分析时，z 的 Lifetime 为函数 foo 返回值的 Lifetime 'a，它小于变量 x 的生命周期，因此如果 rust 不强制执行 Lifetime 的推导规则，则上述代码能通过静态分析，但若运行时函数 foo 返回了 y，则又产生了内存安全的问题。上例中的 random 函数修复如下：

fn foo<'a, 'b: 'a>(x: &'a str, y: &'b str) -> &'a str

'b: 'a 表示 Lifetime 'b 比 'a 活得长 (outlive)。因此可以通过 Lifetime 规则。

如上，即使 rust 需要我们人工指定一些生命周期，它对指定的内容也是有要求的，要求就是函数返回值的生命周期要小于任意一个参数的生命周期，这样静态分析的结果才能保证运行时的正确性。

小结

内存安全、数据竞争等问题的根源是“共享可变数据”，C/C++ 语言将这些问题完全交结程序员，由程序员保证不出错；Java 采用 GC 解决内存回收问题，但依旧面临着数据竞争等问题，需要程序员处理；一些函数式语言，诸如 Haskell, Clojure 针对“共享可变数据”中的“可变”，强制要求数据是“不可变”的，以解决上述问题；而 rust 另辟蹊径处理了“共享”的问题，来达到同样的效果。

当然，在编程语言降低我们出错风险的同时，也剥夺了我们的“自由”与“权力”。有些语言让我们付出的代价是性能，而 rust 需要的则是程序员付出更多的学习时间。

参考资料