学习笔记 20240806 Rust语言-Deref解引用，Drop释放资源

最新推荐文章于 2024-09-14 21:53:48 发布

zhangfan-辰祎

最新推荐文章于 2024-09-14 21:53:48 发布

阅读量1k

点赞数 16

文章标签：学习笔记 rust

本文链接：https://blog.csdn.net/qq_51181223/article/details/140964629

版权

20240806

Deref解引用

在开始之前，我们先来看一段代码：

#[derive(Debug)]
struct Person {
    name: String,
    age: u8
}

impl Person {
    fn new(name: String, age: u8) -> Self {
        Person { name, age}
    }

    fn display(self: &mut Person, age: u8) {
        let Person{name, age} = &self;
    }
}

以上代码有一个很奇怪的地方：在 display 方法中，self 是 &mut Person 的类型，接着我们对其取了一次引用 &self，此时 &self 的类型是 &&mut Person，然后我们又将其和 Person 类型进行匹配，取出其中的值。

那么问题来了，Rust 不是号称安全的语言吗？为何允许将 &&mut Person 跟 Person 进行匹配呢？答案就在本章节中，等大家学完后，再回头自己来解决这个问题 😃 下面正式开始咱们的新章节学习。

何为智能指针？能不让你写出 ****s 形式的解引用，我认为就是智能 😃，智能指针的名称来源，主要就在于它实现了 Deref 和 Drop 特征，这两个特征可以智能地帮助我们节省使用上的负担：

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

先来看看 Deref 特征是如何工作的。

通过 * 获取引用背后的值

在正式讲解 Deref 之前，我们先来看下常规引用的解引用。

常规引用是一个指针类型，包含了目标数据存储的内存地址。对常规引用使用 * 操作符，就可以通过解引用的方式获取到内存地址对应的数据值：

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

    assert_eq!(5, x);
    assert_eq!(5, *y);
}

这里 y 就是一个常规引用，包含了值 5 所在的内存地址，然后通过解引用 *y，我们获取到了值 5。如果你试图执行 assert_eq!(5, y);，代码就会无情报错，因为你无法将一个引用与一个数值做比较：

error[E0277]: can't compare `{integer}` with `&{integer}` //无法将{integer} 与&{integer}进行比较
 --> src/main.rs:6:5
  |
6 |     assert_eq!(5, y);
  |     ^^^^^^^^^^^^^^^^^ no implementation for `{integer} == &{integer}`
  |
  = help: the trait `PartialEq<&{integer}>` is not implemented for `{integer}`
                    // 你需要为{integer}实现用于比较的特征PartialEq<&{integer}>

智能指针解引用

上面所说的解引用方式和其它大多数语言并无区别，但是 Rust 中将解引用提升到了一个新高度。考虑一下智能指针，它是一个结构体类型，如果你直接对它进行 *myStruct，显然编译器不知道该如何办，因此我们可以为智能指针结构体实现 Deref 特征。

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

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

智能指针 x 被 * 解引用为 i32 类型的值 1，然后再进行求和。

定义自己的智能指针

现在，让我们一起来实现一个智能指针，功能上类似 Box<T>。由于 Box<T> 本身很简单，并没有包含类如长度、最大长度等信息，因此用一个元组结构体即可。

struct MyBox<T>(T);

impl<T> MyBox<T> {
    fn new(x: T) -> MyBox<T> {
        MyBox(x)
    }
}

跟 Box<T> 一样，我们的智能指针也持有一个 T 类型的值，然后使用关联函数 MyBox::new 来创建智能指针。由于还未实现 Deref 特征，此时使用 * 肯定会报错：

fn main() {
    let y = MyBox::new(5);

    assert_eq!(5, *y);
}

运行后，报错如下：

error[E0614]: type `MyBox<{integer}>` cannot be dereferenced
  --> src/main.rs:12:19
   |
12 |     assert_eq!(5, *y);
   |                   ^^

为智能指针实现 Deref 特征

现在来为 MyBox 实现 Deref 特征，以支持 * 解引用操作符：

use std::ops::Deref;

impl<T> Deref for MyBox<T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

很简单，当解引用 MyBox 智能指针时，返回元组结构体中的元素 &self.0，有几点要注意的：

在 Deref 特征中声明了关联类型 Target，在之前章节中介绍过，关联类型主要是为了提升代码可读性
deref 返回的是一个常规引用，可以被 * 进行解引用

之前报错的代码此时已能顺利编译通过。当然，标准库实现的智能指针要考虑很多边边角角情况，肯定比我们的实现要复杂。

* 背后的原理

当我们对智能指针 Box 进行解引用时，实际上 Rust 为我们调用了以下方法：

*(y.deref())

其中y.deref()返回&T类型，则*(y.deref())得到T类型。

至于 Rust 为何要使用这个有点啰嗦的方式实现，原因在于所有权系统的存在。如果 deref 方法直接返回一个值，而不是引用，那么该值的所有权将被转移给调用者，而我们不希望调用者仅仅只是 *T 一下，就拿走了智能指针中包含的值。

需要注意的是，* 不会无限递归替换，从 *y 到 *(y.deref()) 只会发生一次，而不会继续进行替换然后产生形如 *((y.deref()).deref()) 的怪物。

函数和方法中的隐式 Deref 转换

对于函数和方法的传参，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(仅引用类型的实参才会触发自动解引用)

连续的隐式 Deref 转换

Deref 可以支持连续的隐式转换，直到找到适合的形式为止：

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

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

这里我们使用了之前自定义的智能指针 MyBox，并将其通过连续的隐式转换变成 &str 类型：首先 MyBox 被 Deref 成 String 类型，结果并不能满足 display 函数参数的要求，编译器发现 String 还可以继续 Deref 成 &str，最终成功的匹配了函数参数。

想象一下，假如 Rust 没有提供这种隐式转换，我们该如何调用 display 函数？

fn main() {
    let m = MyBox::new(String::from("Rust"));
    display(&(*m)[..]);
}

结果不言而喻，肯定是 &s 的方式优秀得多。总之，当参与其中的类型定义了 Deref 特征时，Rust 会分析该类型并且连续使用 Deref 直到最终获得一个引用来匹配函数或者方法的参数类型，这种行为完全不会造成任何的性能损耗，因为完全是在编译期完成。

但是 Deref 并不是没有缺点，缺点就是：如果你不知道某个类型是否实现了 Deref 特征，那么在看到某段代码时，并不能在第一时间反应过来该代码发生了隐式的 Deref 转换。事实上，不仅仅是 Deref，在 Rust 中还有各种 From/Into 等等会给阅读代码带来一定负担的特征。还是那句话，一切选择都是权衡，有得必有失，得了代码的简洁性，往往就失去了可读性。

再来看一下在方法、赋值中自动应用 Deref 的例子：

fn main() {
    let s = MyBox::new(String::from("hello, world"));
    let s1: &str = &s;
    let s2: String = s.to_string();
}

对于 s1，我们通过两次 Deref 将 &str 类型的值赋给了它 （赋值操作需要手动解引用）,这里的手动是指只用&s无法得到我们想要的&str,需要在类型标注时手动写上我们想要的类型&str,即"let s1:&str = …"冒号后面的部分，剩下的可以靠隐式Deref来实现将&s(类型为&MyBox<String>)转换为我们想要的&str；

而对于 s2，我们在其上直接调用方法 to_string，实际上 MyBox 根本没有没有实现该方法，能调用 to_string，完全是因为编译器对 MyBox 应用了 Deref 的结果 （方法调用会自动解引用）。

Deref规则总结

在上面，我们零碎的介绍了不少关于 Deref 特征的知识，下面来通过较为正式的方式来对其规则进行下总结。

一个类型为 T 的对象 foo，如果 T: Deref<Target=U>， 那么，相关 foo 的引用 &foo 在类型标注上会显示&T，但是在应用的时候可以认为会自动转换为 &U，手动标注为&U也就不会出错，并且可以根据隐式Deref来简化一些不必要的显式类型转换。

引用归一化

Rust 编译器实际上只能对 &v 形式的引用进行解引用操作，那么问题来了，如果是一个智能指针或者 &&&&v 类型的呢？该如何对这两个进行解引用？

答案是：Rust 会在解引用时自动把智能指针和 &&&&v 做引用归一化操作，转换成 &v 形式，最终再对 &v 进行解引用：

把智能指针（比如在库中定义的，Box、Rc、Arc、Cow 等）从结构体脱壳为内部的引用类型，也就是转成结构体内部的 &v
把多重&，例如 &&&&&&&v，归一成 &v

关于第二种情况，这么干巴巴的说，也许大家会迷迷糊糊的，我们来看一段标准库源码，也就是说这样的归一化不用自己定义方法，系统默认就有：

impl<T: ?Sized> Deref for &T {
    type Target = T;

    fn deref(&self) -> &T {
        *self
    }
}

在这段源码中，&T 被自动解引用为 T，也就是 &T: Deref<Target=T> 。 按照这个代码，&&&&T 会被自动解引用为 &&&T，然后再自动解引用为 &&T，以此类推，直到最终变成 &T。

几个例子

    fn foo(s: &str) {}

    // 由于 String 实现了 Deref<Target=str>
    let owned = "Hello".to_string();

    // 因此下面的函数可以正常运行：
    foo(&owned);

    use std::rc::Rc;

    fn foo(s: &str) {}

    // String 实现了 Deref<Target=str>
    let owned = "Hello".to_string();
    // 且 Rc 智能指针可以被自动脱壳为内部的 `owned` 引用： &String ，然后 &String 再自动解引用为 &str
    let counted = Rc::new(owned);

    // 因此下面的函数可以正常运行:
    foo(&counted);

    struct Foo;

    impl Foo {
        fn foo(&self) { println!("Foo"); }
    }

    let f = &&Foo;

    f.foo();
    (&f).foo();
    (&&f).foo();
    (&&&&&&&&f).foo();

三种 Deref 转换

在之前，我们讲的都是不可变的 Deref 转换，实际上 Rust 还支持将一个可变的引用转换成另一个可变的引用以及将一个可变引用转换成不可变的引用，规则如下：

当 T: Deref<Target=U>，可以将 &T 转换成 &U，也就是我们之前看到的例子
当 T: DerefMut<Target=U>，可以将 &mut T 转换成 &mut U
当 T: Deref<Target=U>，可以将 &mut T 转换成 &U

来看一个关于 DerefMut 的例子：

struct MyBox<T> {
    v: T,
}

impl<T> MyBox<T> {
    fn new(x: T) -> MyBox<T> {
        MyBox { v: x }
    }
}

use std::ops::Deref;

impl<T> Deref for MyBox<T> {
    type Target = T;

    fn deref(&self) -> &Self::Target {
        &self.v
    }
}

use std::ops::DerefMut;

impl<T> DerefMut for MyBox<T> {
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.v
    }
}

fn main() {
    let mut s = MyBox::new(String::from("hello, "));
    display(&mut s)
}

fn display(s: &mut String) {
    s.push_str("world");
    println!("{}", s);
}

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

要实现 DerefMut 必须要先实现 Deref 特征：pub trait DerefMut: Deref
T: DerefMut<Target=U> 解读：将 &mut T 类型通过 DerefMut 特征的方法转换为 &mut U 类型，对应上例中，就是将 &mut MyBox<String> 转换为 &mut String

对于上述三条规则中的第三条，它比另外两条稍微复杂了点：Rust 可以把可变引用隐式的转换成不可变引用，但反之则不行。

如果从 Rust 的所有权和借用规则的角度考虑，当你拥有一个可变的引用，那该引用肯定是对应数据的唯一借用，那么此时将可变引用变成不可变引用并不会破坏借用规则；但是如果你拥有一个不可变引用，那同时可能还存在其它几个不可变的引用，如果此时将其中一个不可变引用转换成可变引用，就变成了可变引用与不可变引用的共存，最终破坏了借用规则。

总结

Deref 可以说是 Rust 中最常见的隐式类型转换，而且它可以连续的实现如 Box<String> -> String -> &str 的隐式转换，只要链条上的类型实现了 Deref 特征。

我们也可以为自己的类型实现 Deref 特征，但是原则上来说，只应该为自定义的智能指针实现 Deref。例如，虽然你可以为自己的自定义数组类型实现 Deref 以避免 myArr.0[0] 的使用形式，但是 Rust 官方并不推荐这么做，特别是在你开发三方库时。

Drop释放资源

在 Rust 中，我们之所以可以一拳打跑 GC 的同时一脚踢翻手动资源回收，主要就归功于 Drop 特征，同时它也是智能指针的必备特征之一。

学习目标：如何自动和手动释放资源及执行指定的收尾工作

Rust 中的资源回收

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

GC，即垃圾收集（Garbage Collection），是一种自动内存管理机制，用于自动回收程序中不再使用的内存资源。
OOM问题，全称为"Out of Memory"（内存耗尽），是指计算机程序在运行过程中因为无法获得足够的内存资源而无法继续执行的情况。

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

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

一个不那么简单的 Drop 例子

struct HasDrop1;
struct HasDrop2;
struct HasDrop3;
impl Drop for HasDrop1 {
    fn drop(&mut self) {
        println!("Dropping HasDrop1!");
    }
}
impl Drop for HasDrop2 {
    fn drop(&mut self) {
        println!("Dropping HasDrop2!");
    }
}
impl Drop for HasDrop3 {
  fn drop(&mut self) {
      println!("Dropping HasDrop3!");
  }
}
struct HasThreeDrops {
    one: HasDrop1,
    two: HasDrop2,
    three: HasDrop3,
}
impl Drop for HasThreeDrops {
    fn drop(&mut self) {
        println!("Dropping HasThreeDrops!");
    }
}

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        println!("Dropping Foo!")
    }
}

fn main() {
    let _x = HasThreeDrops {
      two: HasDrop2, 
      one: HasDrop1,
      three: HasDrop3,
    };
    let _foo = Foo;
    println!("Running!");
}

上面代码虽然长，但是目的其实很单纯，就是为了观察不同情况下变量级别的、结构体内部字段的 Drop，有几点值得注意：

Drop 特征中的 drop 方法借用了目标的可变引用，而不是拿走了所有权，这里先设置一个悬念，后边会讲
结构体中每个字段都有自己的 Drop

来看看输出：

Running!
Dropping Foo!
Dropping HasTwoDrops!
Dropping HasDrop1!
Dropping HasDrop2!
Dropping HasDrop3!

最终每个资源都成功的执行了收尾工作。

Drop 的顺序

观察以上输出，我们可以得出以下关于 Drop 顺序的结论:

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

没有实现 Drop 的结构体

实际上，就算你不为 _x 结构体实现 Drop 特征，它内部的三个字段依然会调用 drop，移除以下代码，并观察输出：

impl Drop for HasThreeDrops {
    fn drop(&mut self) {
        println!("Dropping HasThreeDrops!");
    }
}

原因在于，Rust 自动为几乎所有类型都实现了 Drop 特征，因此就算你不手动为结构体实现 Drop，它依然会调用默认实现的 drop 函数，同时再调用每个字段的 drop 方法，最终打印出：

Running!
Dropping Foo!
Dropping HasTwoDrops!
Dropping HasDrop1!
Dropping HasDrop2!
Dropping HasDrop3!

手动回收

当使用智能指针来管理锁的时候，你可能希望提前释放这个锁，然后让其它代码能及时获得锁，此时就需要提前去手动 drop。但是在之前我们提到一个悬念，Drop::drop 只是借用了目标值的可变引用，所以，就算你提前调用了 drop，后面的代码依然可以使用目标值，但是这就会访问一个并不存在的值，非常不安全，好在 Rust 会阻止你：

#[derive(Debug)]
struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        println!("Dropping Foo!")
    }
}

fn main() {
    let foo = Foo;
    foo.drop();
    println!("Running!:{:?}", foo);
}

报错如下：

error[E0040]: explicit use of destructor method
  --> src/main.rs:37:9
   |
37 |     foo.drop();
   |     ----^^^^--
   |     |   |
   |     |   explicit destructor calls not allowed
   |     help: consider using `drop` function: `drop(foo)`

如上所示，编译器直接阻止了我们调用 Drop 特征的 drop 方法，原因是对于 Rust 而言，不允许显式地调用析构函数（这是一个用来清理实例的通用编程概念）。好在在报错的同时，编译器还给出了一个提示：使用 drop 函数。

针对编译器提示的 drop 函数，我们可以大胆推测下：它能够拿走目标值的所有权。现在来看看这个猜测正确与否，以下是 std::mem::drop 函数的签名：

pub fn drop<T>(_x: T)

如上所示，drop 函数确实拿走了目标值的所有权，来验证下：

fn main() {
    let foo = Foo;
    drop(foo);
    // 以下代码会报错：借用了所有权被转移的值
    // println!("Running!:{:?}", foo);
}

Bingo，完美拿走了所有权，而且这种实现保证了后续的使用必定会导致编译错误，因此非常安全！

细心的同学可能已经注意到，这里直接调用了 drop 函数，并没有引入任何模块信息，原因是该函数在std::prelude里。

Drop 使用场景

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

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

对于第二点，在之前我们已经详细介绍过，因此这里主要对第一点进行下简单说明。

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

互斥的 Copy 和 Drop

我们无法为一个类型同时实现 Copy 和 Drop 特征。因为实现了 Copy 的特征会被编译器隐式的复制，因此非常难以预测析构函数执行的时间和频率。因此这些实现了 Copy 的类型无法拥有析构函数。

#[derive(Copy)]
struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        println!("Dropping Foo!")
    }
}

以上代码报错如下：

error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
  --> src/main.rs:24:10
   |
24 | #[derive(Copy)]
   |          ^^^^ Copy not allowed on types with destructors