这是关于零拷贝反序列化有趣抽象的三部分系列的第三篇。这一部分将彻底消除反序列化步骤。第一部分是关于使其更易用，可在此找到；第二部分是关于使其适用于更多类型，可在此找到。文章可以按任何顺序阅读，但只有第一篇解释了零拷贝反序列化是什么。

当亚历山大看到自己作品的广度时，他哭了。因为再也没有拷贝可以归零了。

——汉斯·格鲁伯，在设计了三个越来越疯狂的零拷贝crate之后

本系列的第一部分试图回答“我们如何使零拷贝反序列化更愉快”这个问题，而第二部分回答了“我们如何使零拷贝反序列化更有用？”。

这更进一步，提出：“如果我们能完全避免反序列化会怎样？”。

等等，什么？

请听我解释。

正如前面文章中提到的，像ICU4X这样的国际化库需要能够加载和管理大量的国际化数据。ICU4X特别希望这个过程尽可能灵活和高效。对效率的关注是我们几乎对所有东西都使用零拷贝反序列化的原因，而对灵活性的关注则催生了一个强大且可插拔的数据加载基础设施，允许您混合搭配数据源。

反序列化是加载数据的一种绝佳方式，因为它本身就相当灵活！您可以将数据打包成一个小巧的包裹，然后从文件系统加载它！或者通过网络发送！当您拥有像零拷贝反序列化这样高效的技术时，成本很低，效果就更好了。

但问题在于，仍然存在成本。即使采用零拷贝反序列化，您也必须验证接收到的数据。这通常是人们愿意付出的代价，但并非总是如此。

例如，假设您是一个希望使用ICU4X的Web浏览器，您非常关心启动时间。浏览器在启动时（以及打开新标签页时）通常需要设置许多东西，为了给用户提供流畅的体验，每一毫秒都至关重要。浏览器通常也已经附带了所需的大部分国际化数据。将宝贵的时间花在反序列化您随身携带的数据上是不理想的。

理想情况下，它应该像这样工作：

static DATA: &Data = &serde_json::deserialize!(include_bytes!("./testdata.json"));

数据可以在编译时反序列化并加载到静态变量中。不幸的是，Rust的const支持尚未达到可以在serde的泛型框架内实现上述代码的阶段，尽管可能在一年左右后实现。

您可以编写一个非常不安全的serde::Deserialize版本，它操作完全可信的数据，并使用某种易于零拷贝反序列化且避免任何验证的数据格式。然而，这仍然会有一些成本：您仍然需要扫描数据以重构完整的反序列化输出。更重要的是，它将需要一个并行的不安全serde-like trait宇宙，每个人都必须派生或实现，其中即使是手动实现中的小错误也可能导致内存损坏。

听起来你需要一种无需验证或扫描即可零拷贝反序列化，并且可以安全生成的格式。但这种格式不存在，对吧？

它存在。

……但你不会喜欢我接下来要讲的。

哦，不。

确实存在这样一种格式：Rust代码。具体来说，是static中的Rust代码。编译后，Rust的static加载基本上是“免费”的，除了将内存页面调入时涉及的典型成本。Rust编译器信任自己擅长代码生成，因此在从内存加载已编译的static时不需要验证。不过，可能存在代码生成错误，但我们对程序的其他部分也必须信任编译器这一点！

这甚至比“零拷贝反序列化”更“零”。常规的“零拷贝反序列化”仍然涉及扫描甚至验证步骤，它更多的是关于“零分配”，而不是真正避免所有复制。另一方面，当您加载Rust statics时，确实没有任何复制或其他操作；它已经作为一个&'static引用准备就绪！

我们只需要找到一种方法将数据“序列化为const Rust代码”，这样生成的Rust代码就可以直接编译进二进制文件，需要将可信数据加载到ICU4X中的人们就可以免费加载它了！

在这个上下文中，“const代码”是什么意思？

在Rust中，const代码本质上是可被证明没有副作用的代码，并且它是唯一允许在static、const和const fn中使用的代码类型。

我明白了！这段代码实际上必须是“常量”吗？

不完全是！Rust支持在const代码中使用突变甚至像for循环这样的东西！最终，它必须是那种可以在编译时计算且行为没有差异的代码：因此不能读取文件或网络，也不能使用随机数。

很长一段时间内，const只允许非常简单的代码，但在过去一年里，该环境能做的事情范围已经大大扩展，实际上可以在这里做复杂的事情，这正是使我们能够以合理方式实现“序列化为Rust代码”的关键。

databake

此处的很多设计也可以在设计文档中找到。虽然我负责了这个crate的主要设计，但它几乎完全由Robert实现，他还致力于将其集成到ICU4X中，并在此过程中清理了设计。

这就是databake（原名crabbake）。databake是一个提供此功能的crate；能够将您的类型序列化为const代码，然后可在static中使用，从而实现真正的零成本数据加载，无需反序列化！

databake的核心入口点是Bake trait：

pub trait Bake {
    fn bake(&self, ctx: &CrateEnv) -> TokenStream;
}

TokenStream是通常在Rust过程宏中用于表示一段Rust代码的类型。Bake trait允许您获取一个类型的实例，并将其转换为表示相同值的Rust代码。

CrateEnv对象用于跟踪需要哪些crate，以便生成此代码的工具可以告知用户需要哪些直接依赖项。

此trait通过#[derive(Bake)]自定义派生宏进行增强，可将其自动应用于大多数类型：

// inside crate `bar`, module `module.rs`

use databake::Bake;

#[derive(Bake)]
#[databake(path = bar::module)]
pub struct Person<'a> {
   pub name: &'a str,
   pub age: u32,
}

与大多数自定义派生宏一样，这仅适用于包含其他已实现Bake类型的结构体和枚举。大多数不涉及强制分配的类型都应该能够实现。

如何使用它

databake本身并不规定任何特定的代码生成策略。它可以在过程宏中、build.rs中使用，甚至可以在单独的二进制文件中使用。ICU4X采用后者，因为这正是ICU4X数据生成模型的工作方式：客户端可以使用该二进制文件来自定义所需数据的格式和内容。

因此，使用此crate的一种典型方式可能是在build.rs中这样做：

use some_dep::Data;
use databake::Bake;
use quote::quote;

fn main() {
   // load data from file
   let json_data = include_str!("data.json");

   // deserialize from json
   let my_data: Data = serde_json::from_str(json_data);

   // get a token tree out of it
   let baked = my_data.bake();


   // Construct rust code with this in a static
   // The quote macro is used by procedural macros to do easy codegen,
   // but it's useful in build scripts as well.
   let my_data_rs = quote! {
      use some_dep::Data;
      static MY_DATA: Data = #baked;
   }

   // Write to file
   let out_dir = env::var_os("OUT_DIR").unwrap();
   let dest_path = Path::new(&out_dir).join("data.rs");
   fs::write(
      &dest_path,
      &my_data_rs.to_string()
   ).unwrap();

   // (Optional step omitted: run rustfmt on the file)

   // tell Cargo that we depend on this file
   println!("cargo:rerun-if-changed=src/data.json");
}

它看起来像什么

ICU4X将其所有测试数据生成为JSON、postcard和“baked”格式。例如，对于表示特定语言环境如何处理数字的这个JSON数据，“baked”数据看起来像这样。这是一个相当简单的数据类型，但我们也用它处理更复杂的数据，比如日期时间符号数据，可惜它太大了，GitHub无法正常渲染。

ICU4X生成此数据的代码在此文件中。它很复杂主要是因为ICU4X的数据生成管道高度可配置且复杂。它所做的核心事情是，对于每一块数据，它调用tokenize()，这是对数据调用.bake()并进行其他操作的一个薄包装。然后它获取所有数据并将其组织成类似上面链接的文件，每个数据块都有一个静态变量。在我们的例子中，我们将所有这些生成的Rust代码作为一个模块包含在我们的“testdata”crate中，但这里有很多可能性！

对于我们的“测试”数据，目前以postcard格式（针对轻量级优化）是2.7 MB，相同的数据最终在JSON中是11 MB，在生成的Rust代码中是18 MB！那……是大量的Rust代码，rust-analyzer等工具加载它都很吃力。不过，一旦编译进二进制文件，它当然会小得多，但这更难衡量，因为在baked版本中，Rust非常积极地将未使用的数据优化掉（它有充足的机会这样做）。从各种非正式测试来看，大约2MB的去重postcard数据对应约500KB的去重baked数据。这是合理的，因为可以预期baked数据接近不应用一些重度压缩的数据的理论最小值。此外，虽然我们在每语言环境级别去重baked数据，但它可以利用LLVM进一步去重statics的能力，因此，例如，如果两个不同的语言环境对于给定数据键¹的数据大部分相同但有些差异，LLVM可能可以使用相同的statics来处理子数据。

局限性

Rust中的const支持还有很长的路要走。例如，它还不支持创建通常在堆上的对象，如String，尽管他们正在努力允许这样做。这对我们来说不是大问题；我们所有的数据都已经支持零拷贝反序列化，这意味着对于我们的每个数据类型实例，都有某种方式将其表示为另一个static的借用。

一个更麻烦的限制是您无法在const环境中与trait交互。在某种程度上，如果可能的话，使serde管道支持const²也可以实现此crate的目的，那么本文开头的代码片段就可以工作：

static DATA: &Data = &serde_json::deserialize!(include_bytes!("./testdata.json"));

这意味着对于像ZeroVec（参见第二部分）这样的东西，我们实际上无法仅仅使其安全构造函数为const并传入待验证的数据——验证代码都在trait后面——因此我们必须不安全地构造它们。这有点不幸，但最终如果zerovec的字节表示往返有问题，我们会有更大的麻烦，所以这不是引入新的不安全表面。我们仍然能够在生成baked数据时进行验证，只是无法让编译器在同意编译const代码之前重新验证。

试一试！

databake与yoke和zerovec相比成熟度低得多，但到目前为止它似乎运行得相当好。试试看！让我知道你的想法！

感谢Finch、Jane、Shane和Robert审阅本文草稿

1. 在ICU4X中，“数据键”可用于指代特定类型的数据，例如小数符号数据具有decimal/symbols@1数据键。↩

2. 请注意，这并非易事，但它很可能会与生态系统很好地集成。↩

由 mimo-v2.5 模型翻译，花费 14361 tokens

这是我关于零拷贝反序列化的一些有趣抽象概念的三部分系列文章的第二部分。第一部分是关于使其更易于使用，可以在这里找到；而第三部分是关于完全消除反序列化步骤，可以在这里找到。这些文章可以按任何顺序阅读，但只有第一篇包含了对什么是零拷贝反序列化的解释。

背景

本节与上一篇文章相同，如果您已经读过，可以跳过。

在过去的一年半里，我一直全职参与ICU4X的工作，这是一个在Unicode联盟下由多家公司协作构建的新的国际化库。

关于ICU4X我能说的很多，但为了聚焦一个核心价值主张：我们希望它在数据和代码方面都是模块化的。我们希望ICU4X能在嵌入式平台上使用，因为那里内存很宝贵。我们希望受下载大小限制的应用程序能够支持所有语言，而不是因为无法负担打包所有数据而只能选择少数几种流行语言。为此，我们希望数据加载是快速的且可插拔的。用户应该能够为他们的具体用例设计自己的数据加载策略。

请注意，执行正确国际化的一个关键部分是数据。不同的区域设置¹有不同的做法，所有关于这些的信息都需要有地方存储，最好不要放在代码里。你需要数据来说明特定区域设置如何格式化日期²，或者特定语言中复数如何工作，或者如何准确地分割像泰语这样通常没有空格分隔的语言，以便在适当的位置插入换行符。

鉴于对数据的关注，一个对我们来说非常有吸引力的选择是零拷贝反序列化。在努力做好零拷贝反序列化的过程中，我们构建了一些很酷的新库，本文就是关于其中一个的。

哪些东西可以零拷贝？

如果您不熟悉零拷贝反序列化，请查看上一篇文章中的解释！

在上一篇文章中，我们探讨了通过消除生命周期（lifetime）如何使零拷贝反序列化更易于使用。本质上，我们是在扩展你能用零拷贝数据做什么的能力。

本文是关于扩展我们能制作什么为零拷贝数据。

我们之前看到了这个结构体：

#[derive(Serialize, Deserialize)]
struct Person {
    // 此字段的构造几乎免费
    age: u8,
    // 构造此字段将涉及一次小的内存分配和复制
    name: String,
    // 这可能需要一些时间
    rust_files_written: Vec<String>,
}

并通过将其替换为Cow<'a, str>使name字段实现了零拷贝。然而，我们无法对rust_files_written字段做同样的事情，因为serde除了[u8]和str之外，并不处理其他事物的零拷贝反序列化。更不用说像Vec<String>（作为&[&str]）这样的嵌套集合了，即使是Vec<u32>（作为&[u32]）也无法轻松实现零拷贝！

这并不是零拷贝反序列化中的一个根本性限制，事实上，优秀的rkyv库能够支持这样的数据。然而，它不像str和[u8]那样唾手可得，serde希望不在这方面选择任何权衡，而是将其留给用户，这是可以理解的。

那么，这里真正的问题是什么？

字节序、对齐和间接寻址之惑

简短的回答是：字节序、对齐，以及对于Vec<String>，还有间接寻址。

请看，零拷贝反序列化的工作方式是直接获取指向内存的指针并将其声明为期望的值。为了使其工作，该数据必须是在所有机器上看起来相同的类型，并且可以合法地获取其引用。

这对[u8]和str来说非常直接，它们的数据在每个系统上都是相同的。虽然str确实需要一个验证步骤来确保它是有效的UTF-8，但零拷贝序列化的总体思路是用更便宜的验证来替代昂贵的反序列化，所以我们对此没有问题。

另一方面，Vec<String>的借用版本&[&str]即使在同一个系统上程序的不同执行中，也不太可能看起来相同，因为它包含指针（间接寻址），这些指针会根据数据源在每次执行时发生变化！

指针很棘手。那Vec<u32>/[u32]呢？一堆整数总该没问题了吧？

这就是字节序和对齐发挥作用的地方。首先，一个u32在不同系统上并非完全相同，有些系统是“大端字节序”，整数0x00ABCDEF在内存中会表示为[0x00, 0xAB, 0xCD, 0xEF]，而其他系统是“小端字节序”，会表示为[0xEF, 0xCD, 0xAB, 0x00]。如今大多数系统是小端字节序，但并非全部，所以你可能需要关心这一点。

这意味着，如果我们在小端字节序系统上序列化一个[u32]，然后天真地在大端字节序系统上进行零拷贝反序列化，它会完全乱码。

其次，许多系统对像u32这样的类型施加对齐限制。一个u32不能在任意旧的内存地址上找到，在大多数现代系统上，它必须位于4的倍数的内存地址上。类似地，一个u64必须位于8的倍数的内存地址上，依此类推。然而，正在序列化的数据子部分可能位于任何地址。可以设计一个序列化框架，强制数据中的特定字段具有特定的对齐方式（rkyv具有此功能），但这有点棘手，并且需要你对原始加载数据的对齐方式有控制权，而这并不是serde模型的一部分。

那么我们如何解决这个问题呢？

ZeroVec 和 VarZeroVec

此处的许多设计可以在设计文档中找到说明

在与Shane进行了大量讨论之后，我们设计并编写了zerovec，这是一个试图以与serde兼容的方式解决此问题的crate。

该crate的核心抽象是两种类型：ZeroVec和VarZeroVec，它们本质上是零拷贝启用的Cow<'a, [T]>版本，分别用于固定大小和可变大小的T类型。

ZeroVec可以用于任何实现ULE的类型（稍后会解释其含义），默认情况下包括所有整数类型，并且可以扩展到大多数Copy类型。它类似于&[T]，但返回的是其元素的副本而不是引用。虽然ZeroVec是一个类似Cow的借用或拥有类型³，但有一个完全借用的变体ZeroSlice，它可以被解引用得到。

类似地，VarZeroVec可以与实现VarULE的类型一起使用（例如str）。它能够提供引用，VarZeroVec<str>的行为非常类似于&[str]在Rust中允许存在的行为。你甚至可以嵌套它们，制作像VarZeroVec<VarZeroSlice<ZeroSlice<u32>>>这样的类型，它是Vec<Vec<Vec<u32>>>的零拷贝等价物。

还有一个ZeroMap类型，它提供了一个基于二分搜索的映射，可与ZeroVec或VarZeroVec兼容的类型一起工作。

例如，要使以下结构体零拷贝：

#[derive(serde::Serialize, serde::Deserialize)]
struct DataStruct {
    nums: Vec<u32>,
    chars: Vec<char>,
    strs: Vec<String>,
}

你可以这样做：

#[derive(serde::Serialize, serde::Deserialize)]
pub struct DataStruct<'data> {
    #[serde(borrow)]
    nums: ZeroVec<'data, u32>,
    #[serde(borrow)]
    chars: ZeroVec<'data, char>,
    #[serde(borrow)]
    strs: VarZeroVec<'data, str>,
}

反序列化后，数据可以通过data.nums.get(index)或data.strs[index]等方式进行访问。

自定义类型也可以通过一些努力在这些类型中得到支持，如果你想让以下复杂数据实现零拷贝：

#[derive(Copy, Clone, PartialEq, Eq, Ord, PartialOrd, serde::Serialize, serde::Deserialize)]
struct Date {
    y: u64,
    m: u8,
    d: u8
}

#[derive(Clone, PartialEq, Eq, Ord, PartialOrd, serde::Serialize, serde::Deserialize)]
struct Person {
    birthday: Date,
    favorite_character: char,
    name: String,
}

#[derive(serde::Serialize, serde::Deserialize)]
struct Data {
    important_dates: Vec<Date>,
    important_people: Vec<Person>,
    birthdays_to_people: HashMap<Date, Person>
}

你可以这样做：

// 用于 ZeroVec 的自定义固定大小 ULE 类型
#[zerovec::make_ule(DateULE)]
#[derive(Copy, Clone, PartialEq, Eq, Ord, PartialOrd, serde::Serialize, serde::Deserialize)]
struct Date {
    y: u64,
    m: u8,
    d: u8
}

// 用于 VarZeroVec 的自定义可变大小 VarULE 类型
#[zerovec::make_varule(PersonULE)]
#[zerovec::derive(Serialize, Deserialize)] // 为 PersonULE 添加 Serde 实现
#[derive(Clone, PartialEq, Eq, Ord, PartialOrd, serde::Serialize, serde::Deserialize)]
struct Person<'data> {
    birthday: Date,
    favorite_character: char,
    #[serde(borrow)]
    name: Cow<'data, str>,
}

#[derive(serde::Serialize, serde::Deserialize)]
struct Data<'data> {
    #[serde(borrow)]
    important_dates: ZeroVec<'data, Date>,
    // 注意：VarZeroVec 必须直接引用未确定大小的 ULE 类型
    #[serde(borrow)]
    important_people: VarZeroVec<'data, PersonULE>,
    #[serde(borrow)]
    birthdays_to_people: ZeroMap<'data, Date, PersonULE>
}

不幸的是，内部的“ULE类型”工作原理并没有完全对用户隐藏，特别是对于VarZeroVec兼容的类型，但该crate做了很多努力来使其易于使用。

通常，ZeroVec应用于固定大小且实现Copy的类型，而VarZeroVec则应用于逻辑上包含可变数据量的类型，如向量、映射、字符串和它们的聚合体。VarZeroVec将始终与动态大小类型一起使用，提供对该类型的引用。

我之前提到过这些类型类似于Cow<'a, T>；它们可以以可变拥有的方式处理，但这并不是该crate的主要关注点。特别是，VarZeroVec<T>的修改速度将明显慢于Vec<String>之类的东西，因为所有操作都是在相同的缓冲区格式上完成的。该crate的一般理念是，你可能在性能约束不大的情况下生成数据，但你希望读取数据的操作是快速的。因此，在必要时，该crate会用修改性能来交换反序列化/读取性能。尽管如此，它并不是特别慢，只是需要注意并在必要时进行基准测试。

工作原理

该crate的大部分建立在ULE和VarULE这两个trait之上。两者都是unsafe trait（尽管如上所示，大多数用户无需手动实现它们）。“ULE”代表“未对齐小端字节序”，标记那些没有对齐要求且在不同字节序间具有相同表示（在相关时偏好与小端字节序表示相同）的类型⁴。

还有一个安全的AsULE trait，允许在类型与其对应的ULE类型之间进行转换。

pub unsafe trait ULE: Sized + Copy + 'static {
    // 验证一个字节切片是否适合被视为此类型的引用
    fn validate_byte_slice(bytes: &[u8]) -> Result<(), ZeroVecError>;

    // 省略不太相关的实用方法
}

pub trait AsULE: Copy {
    type ULE: ULE;

    // 转换为 ULE 类型
    fn to_unaligned(self) -> Self::ULE;
    // 从 ULE 类型转换回来
    fn from_unaligned(unaligned: Self::ULE) -> Self;
}

pub unsafe trait VarULE: 'static {
    // 验证一个字节切片是否适合被视为此类型的引用
    fn validate_byte_slice(_bytes: &[u8]) -> Result<(), ZeroVecError>;

    // 从已知有效的字节切片构造对 Self 的引用
    // 这是必要的，因为 VarULE 类型是动态大小的，
    // 这些类型的胖指针的元数据工作方式各不相同
    unsafe fn from_byte_slice_unchecked(bytes: &[u8]) -> &Self;

    // 省略不太相关的实用方法
}

ZeroVec<T>接受AsULE类型，并将其内部存储为其ULE类型的切片（&[T::ULE]）。这样的切片可以自由地进行零拷贝序列化。当你尝试索引一个ZeroVec时，它会将值转换回T，这个操作通常只是一次未对齐加载。

VarZeroVec<T>稍微复杂一些。其内存的开头存储向量中每个元素的索引，然后是所有元素的数据，一个接一个地排列。只要动态大小的数据可以用扁平的方式表示（没有进一步的内部间接寻址），它就可以实现VarULE，从而用于VarZeroVec<T>。str实现了这一点，但ZeroSlice<T>和VarZeroSlice<T>也实现了这一点，允许zerovec类型的无限嵌套！

ZeroMap<T>的工作方式类似于litemap crate，它是一个由两个向量构建的映射，使用二分搜索来查找键。这并不总是像哈希映射那样高效，但它可以通过ZeroVec和VarZeroVec以零拷贝方式工作。有一系列trait基础设施，允许它根据键或值的类型自动为每个键和值向量选择ZeroVec或VarZeroVec。

那 rkyv 呢？

当我们开始这条路时，一个重要的问题是：那rkyv呢？它当时在Rust社区中刚刚受到相当多的关注，看起来是一个很酷的库，目标领域相同。

总的来说，如果你正在寻找零拷贝反序列化，我全心全意推荐看看它！这是一个令人印象深刻的库，投入了很多思考。当我在改进zerovec时，我从rkyv以及与David的一些富有洞察力的讨论中学习了很多，并比较了方法。

对我们来说，主要的症结在于rkyv的工作方式有点独立于serde：它使用自己的trait和自己的序列化机制。我们真的很喜欢serde的模型并希望继续使用它，特别是因为我们希望支持各种人类可读和非人类可读的数据格式，包括postcard，它专门为低资源环境设计。这对于数据交换甚至更为重要；我们希望其他语言编写的程序能够构建和发送数据，而不必受限于特定的线路格式。

zerovec的目标本质上是将rkyv类似的改进引入serde宇宙，而不太打乱那个宇宙。zerovec类型在人类可读格式（如JSON）上序列化为结构的普通人类可读表示，而在二进制格式（如postcard）上，则序列化为紧凑的、零拷贝友好的表示形式，一切正常。

性能如何？

首先我要提到的是rkyv维护着一个非常好的基准测试套件，我真的需要将其与zerovec集成，但还没有做。

为什么不先去做那个呢？它会让你的帖子更好！

嗯，我一直在推迟写这篇帖子，直到我集成了那些基准测试，但执行功能不是这样运作的，此时我宁愿用我手头的基准测试发布，而不是进一步延迟。我可能会稍后用好基准测试更新这篇文章！

哼。

完整的基准测试运行详情可以在这里找到（在1e072b32处通过cargo bench运行）。我提取了一些具体的数据点来说明：

ZeroVec：

通常我们不太关心序列化性能，但这里的序列化很快，因为ZeroVec在内存中总是以其序列化的形式存储。这可能会使修改变慢。获取操作在ZeroVec上稍微慢一点。反序列化性能是我们真正获得优势的地方，有时速度可以超过十倍！

VarZeroVec：

字符串是随机生成的，大小在 2 到 20 个代码点之间选择，对于任何给定行使用相同的字符串集。

在这里，获取操作稍微慢一些，因为它们需要读取索引数组，但对于零拷贝反序列化仍然有相当大的优势。对于更复杂的数据，反序列化的优势会叠加；对于Vec<String>，你可以通过使用Vec<&str>获得大部分优势，但对于更复杂的东西不一定可能。我们目前没有VarZeroVec的修改基准测试，但修改可能很慢，如前所述，它不打算在客户端代码中经常使用。

其中一些仍在变动；例如，我们正在使VarZeroVec的缓冲区格式可配置，以便用户可以选择他们确切的权衡。

试用一下！

类似于yoke，我不认为zerov

由 mimo-v2.5 模型翻译，花费 23999 tokens

这是我过去一年一直在研究的零拷贝反序列化有趣抽象系列的三部分中的第一篇。本部分关注如何让零拷贝反序列化更易于使用。第二部分关注如何使其支持更多类型，可在此处找到链接；第三部分则关注完全消除反序列化步骤，可在此处找到链接。这些文章可以按任何顺序阅读，但本文包含对什么是零拷贝反序列化的解释。

背景

过去一年半，我一直在ICU4X上全职工作，这是一个在Unicode联盟下由多家公司合作构建的新国际化Rust库。

关于ICU4X有很多可以说的，但聚焦一个核心价值主张：我们希望它在数据和代码上都是模块化的。我们希望ICU4X能在内存受限的嵌入式平台上使用。我们希望受下载大小限制的应用程序能够支持所有语言，而不是因为无法负担所有数据的打包而只能选择几种流行语言。作为其中的一部分，我们希望数据加载是快速且可插拔的。用户应该能够为他们的具体用例设计自己的数据加载策略。

你看，执行正确国际化的一个关键部分是数据。不同的区域设置¹做事方式不同，所有这些信息都需要一个地方存放，最好不是代码。你需要关于特定区域设置如何格式化日期²的数据，或者某种语言中复数如何工作，或者如何准确地分割像泰语这样通常不用空格书写的语言以便在适当位置插入换行符。

考虑到对数据的侧重，零拷贝反序列化对我们来说是一个非常有吸引力的选项。在努力做好零拷贝反序列化的过程中，我们构建了一些很酷的新库，本文就是关于其中之一的。

零拷贝反序列化：基础

如果您已经熟悉Rust中的零拷贝反序列化，可以跳过此部分

反序列化通常涉及两个协同完成的任务：验证数据，以及构建可通过程序访问的内存表示形式；即最终的反序列化值。

根据格式，前者通常相当快，但后者可能非常慢，通常涉及任何需要新分配且通常需要大量复制的可变大小数据。

#[derive(Serialize, Deserialize)]
struct Person {
    // 这个字段的构造几乎是免费的
    age: u8,
    // 构造这个字段将涉及一次小型分配和复制
    name: String,
    // 这个可能需要一些时间
    rust_files_written: Vec<String>,
}

典型的二进制数据格式可能会将其存储为一个字节的age，后跟name的长度，再后跟name的字节，再后跟向量的另一个长度，最后是每个String值的长度和字符串数据。反序列化u8类型的age只需读取它，但另外两个字段需要分配足够的内存并复制每个字节，此外还可能需要类型所需的任何验证。

这种情况下的一种常见技术是跳过分配和复制，只需验证字节并存储对原始数据的引用。这只能在数据在序列化文件和反序列化值中表示方式完全相同的序列化格式中完成。

在Rust中使用serde时，通常通过使用带#[serde(borrow)]的Cow<'a, T>来完成：

#[derive(Serialize, Deserialize)]
struct Person<'a> {
    age: u8,
    #[serde(borrow)]
    name: Cow<'a, str>,
}

现在，当反序列化name时，反序列化器只需验证它确实是一个有效的UTF-8 str，而name的最终值将是与正在反序列化的原始数据本身的引用。

也可以使用&'a str代替Cow，但这使得Deserialize实现的通用性大大降低，因为那些不将字符串存储为其内存表示形式的格式（例如，包含转义符的JSON字符串）将无法回退到拥有所有权的值。因此，在编写参与零拷贝反序列化的Rust代码时，拥有所有权或借用的Cow<'a, T>通常是良好设计的基石。

age字段这里难道不是仍然在发生复制吗？

是的，“零拷贝”多少有些用词不当，它真正的意思是“零分配”，或者，“零大量复制”。这样看：像age这样的数据确实会被复制，但如果没有，比如说，分配一个Person<'a>的向量，你只会在单独反序列化几个Person<'a>时或反序列化包含几个Person<'a>的某个结构体时看到这种复制。要发生一次不涉及分配的大复制，你的类型必须在栈上本身就是那么大，而人们通常避免这样做，因为这意味着即使在非反序列化情况下，每次移动值时都会发生大复制。

当生活给你生命周期时……

Rust中的零拷贝反序列化有一个非常烦人的缺点：生命周期。突然间，你所有的反序列化类型上都有了生命周期。它们当然会有；它们不再是自包含的，而是包含了对它们最初反序列化数据的引用！

这也不是Rust独有的问题，零拷贝反序列化总是会在你的类型之间引入更复杂的依赖关系，不同的框架处理方式不同；从将生命周期管理留给用户，到使用引用计数或GC来确保数据保持存在。Rust序列化库如果愿意也可以做类似的事情。在这种情况下，serde以非常Rust的方式，希望库用户能够精确控制这里的内存管理，并将此问题作为生命周期呈现出来。

不幸的是，这样的生命周期往往会渗透到所有地方。每个持有你反序列化类型的类型现在都需要一个生命周期，而且很可能会成为你的用户的问题。

此外，Rust生命周期是纯编译时构造。如果你的值是具有生命周期的类型，你需要在编译时知道它肯定不再被使用的时间，并且你需要一直持有其源数据直到那时。Rust的设计意味着你不需要担心弄错，因为编译器会抓住你，但你仍然需要去做。

所有这些对于你想要在运行时管理生命周期的情况并不理想，例如，如果你的数据是从一个更大的文件反序列化来的，并且你希望只要从其反序列化的数据仍然存在，就缓存加载的文件。

通常在这样的情况下你可以使用Rc<T>，它实际上是&'a T安全共享引用的“运行时而非编译时”版本，但这只适用于你共享同构类型的情况，而在这种情况下我们试图共享从一个数据块反序列化的不同类型，而该数据块本身又是另一种类型。

ICU4X希望用户能够根据需要使用缓存和其他数据管理策略，所以这完全行不通。有一段时间ICU4X不是在其大多数类型中贯穿一个而是两个普遍的生命周期：这既令人困惑，也不符合我们的目标。

……让生活收回那些生命周期

这里很多设计可以在设计文档中找到解释

在一番讨论之后，主要是与Shane进行的，我设计了yoke，一个试图通过自引用类型在Rust中提供生命周期擦除的crate。

等等，生命周期擦除？

就像类型擦除一样！“类型擦除”（在Rust中通过dyn Trait完成）让你可以将编译时概念（值的类型）转移到可以在运行时决定的东西中。类似地，yoke的核心价值主张是获取那些背负着生命周期编译时概念的类型，并允许你无论如何在运行时决定它们。

Rc<T>不是已经让你能够将生命周期作为运行时决定吗？

算是吧，Rc<T>本身让你能够避免编译时生命周期，而Yoke则适用于已经存在一个生命周期（例如由于零拷贝反序列化）并且你想要掩盖它的情况。

酷！那是什么样子的？

总体思路是，你可以获取一个零拷贝可反序列化的类型，如Cow<'a, str>（或更复杂的类型），并将其“套索”到它反序列化自的值上，我们称其为“运载车”。

*呻吟* 又一个用双关语命名的crate，Manish。

我永远不会停止。

无论如何，这就是它的样子。

// 为了清晰起见，显式提及一些类型

// 加载一个文件
let file: Rc<[u8]> = fs::read("data.postcard")?.into();

// 通过克隆它创建一个对文件数据的新Rc引用，
// 然后将其用作Yoke的运载车
let y: Yoke<Cow<'static, str>, Rc<[u8]>> = Yoke::attach_to_cart(file.clone(), |contents| {
    // 从文件反序列化
    let cow: Cow<str> =  postcard::from_bytes(&contents);
    cow
})

// 该字符串仍然可以通过 `.get()` 访问
println!("{}", y.get())

drop(y);
// 只有现在文件的引用计数才会减少

这里的一些API由于当前的编译器错误可能无法完全正常工作。在这篇博客文章中，我使用这些API的理想版本进行说明，但值得查看Yoke文档以了解是否需要使用备用的解决方法API。截至Rust 1.61，大多数错误已被修复。

上面的例子使用了postcard：postcard是一个非常棒的兼容serde的二进制序列化格式，专为资源受限环境设计。它相当快且代码量小，请查看一下！

类型Yoke<Cow<'static, str>, Rc<[u8]>>是“一个生命周期擦除的Cow<str>，‘套索’到一个作为Rc<[u8]>的支持数据存储‘运载车’上”。这意味着Cow包含了对运载车中数据的引用，然而，Yoke将持有运载车类型直到它完成，这确保了Cow中的引用不再悬垂。

Yoke中数据的大多数操作都通过.get()进行，在这种情况下，它将返回一个Cow<'a, str>，其中'a是.get()借用的生命周期。这保持了安全性：在这种情况下，分发Cow<'static, str>实际上并不安全，因为Cow实际上并非借用自静态数据；但只要我们在访问期间将生命周期转换为更短的，这就可以了。

事实证明，Yoke类型中的'static实际上是一个谎言！Rust并不真正允许你使用包含借用内容的类型而不提及某些生命周期，在这里我们希望将编译器从管理生命周期的职责中解脱出来，自己管理它们，所以我们需要给它一些东西以便我们可以命名类型，而'static是Rust中唯一预先存在的命名生命周期。

.get()的实际签名有点奇怪，因为它需要是泛型的，但如果我们的借用类型是Foo<'a>，那么.get()的签名大致如下：

impl Yoke<Foo<'static>> {
    fn get<'a>(&'a self) -> &'a Foo<'a> {
        ...
    }
}

要允许一个类型在Yoke<Y, C>中，它必须实现Yokeable<'a>。这个trait手动实现是unsafe的，在大多数情况下你应该使用#[derive(Yokeable)]自动派生：

#[derive(Yokeable, Serialize, Deserialize)]
struct Person<'a> {
    age: u8,
    #[serde(borrow)]
    name: Cow<'a, str>,
}

let person: Yoke<Person<'static>, Rc<[u8]> = Yoke::attach_to_cart(file.clone(), |contents| {
    postcard::from_bytes(&contents)
});

与大多数#[derive]不同，Yokeable即使字段尚未实现Yokeable也可以派生，除非生命周期字段同时具有其他泛型参数的情况。在这些情况下，通常只需用#[yoke(prove_covariance_manually)]标记类型并确保任何具有生命周期的字段也实现了Yokeable即可。

你可以用Yoke做更多的事情，例如，你可以“投影”一个套索以获得一个具有初始套索中数据子集的新套索：

let person: Yoke<Person<'static>, Rc<[u8]>> = ....;

let person_name: Yoke<Cow<'static, str>> = person.project(|p, _| p.name);

这允许将来自不同套索的数据混合使用。

Yoke也是可变的，这或许令人惊讶！毕竟，它们主要是为与写时复制数据一起使用而设计的，所以有方法可以修改它们，前提是没有额外的借用数据潜入：

let mut person: Yoke<Person<'static>, Rc<[u8]>> = ....;

// 让名字听起来更花哨
person.with_mut(|person| {
    // 这将把 `Cow` 转换为拥有所有权的
    person.name.to_mut().push(", Esq.")
})

总的来说，Yoke是一个相当强大的抽象，适用于涉及零拷贝反序列化以及涉及大量借用的其他情况的各种情况。在ICU4X中，我们用于加载数据的抽象总是使用Yoke，允许混合各种数据加载策略——包括缓存。

它是如何工作的

Manish即将说出“协变”这个词，所以我抢先说：如果您难以理解本节和下一节，请不要担心！这个crate的内部工作依赖于多个小众概念，大多数Rust用户即使在处理其他高级代码时也永远不需要关心。

Yoke通过依赖协变生命周期的概念来工作。Yokeable trait看起来像这样：

pub unsafe trait Yokeable<'a>: 'static {
    type Output: 'a;
    // 方法省略
}

一个典型的实现看起来像这样：

unsafe impl<'a> Yokeable<'a> for Cow<'static, str> {
    type Output: 'a = Cow<'a, str>;
    // ...
}

这个trait的一个实现将位于具有生命周期的类型的'static版本上（我将在本文中称其为Self<'static>³），并将其映射到具有生命周期的版本（Self<'a>）。它只能在生命周期'a是协变的类型上实现，也就是说，当'b是更短的生命周期时，将Self<'a>视为Self<'b>是安全的。大多数具有生命周期的类型都属于这一类⁴，特别是在零拷贝反序列化领域。

您可以在nomicon中阅读更多关于型变的信息！

对于任何Yokeable类型Foo<'static>，你可以通过<Foo as Yokeable<'a>>::Output获取该类型的具有生命周期'a的版本。Yokeable trait公开了一些方法，允许人们安全地执行对具有协变生命周期的类型允许的各种转换。

#[derive(Yokeable)]在大多数情况下依赖于编译器确定生命周期是否协变的能力，并且实际上并不生成太多代码！在大多数情况下，Yokeable上各种函数的主体都是纯安全的代码，看起来像这样：

impl<'a> Yokeable for Foo<'static> {
    type Output: 'a = Foo<'a>;
    fn transform(&self) -> &Self::Output {
        self
    }
    fn transform_owned(self) -> Self::Output {
        self
    }
    fn transform_mut<F>(&'a mut self, f: F)
    where
        F: 'static + for<'b> FnOnce(&'b mut Self::Output) {
        f(self)
    }
    // fn make() 省略，因为它不太相关
}

编译器知道这些是安全的，因为它知道该类型是协变的，而Yokeable trait允许我们泛型地讨论这些操作安全的类型。

换句话说，关于生命周期“可拉伸性”有一个编译器知道的有用的属性，我们可以通过生成如果该属性不适用编译器会拒绝编译的代码来检查该属性是否适用于某个类型。

使用这个trait，Yoke然后通过存储Self<'static>并将其转换为更短的、更局部的生命周期，然后再传递给任何消费者来工作，使用Yokeable上的方法以各种方式。知道生命周期是协变的使得这种生命周期“挤压”变得安全。'static是一个谎言，但只要该值实际上不是以'static生命周期访问的，做这种事情是安全的，我们非常小心以确保它不会泄漏。

更好的转换：ZeroFrom

一个与之配合很好的crate是zerofrom，主要由Shane设计和编写。它附带了ZeroFrom trait：

pub trait ZeroFrom<'zf, C: ?Sized>: 'zf {
    fn zero_from(other: &'zf C) -> Self;
}

这个trait的思想是能够泛型地处理可转换为（通常是零拷贝）借用类型。

例如，Cow<'zf, str>既实现了ZeroFrom<'zf, str>也实现了ZeroFrom<'zf, String>，以及ZeroFrom<'zf, Cow<'a, str>>。它类似于AsRef trait，但允许在发生的借用种类上有更多灵活性，并且实现者应该在转换过程中最小化复制量。例如，当ZeroFrom-从某个其他Cow<'a, str>构造一个Cow<'zf, str>时，它将总是构造一个Cow::Borrowed，即使原始的Cow<'a, str>是拥有的。

Yoke有一个方便的构造函数Yoke::attach_to_zero_copy_cart()，如果Y<'zf>对所有生命周期'zf实现了ZeroFrom<'zf, C>，它可以从运载车类型C创建一个Yoke<Y, C>。这对于想要进行基本自引用类型但不进行任何花哨的零拷贝反序列化的情况很有用。

……让生活后悔它曾认为可以给你生命周期

使用这个crate的生活并非全是甜美的。我们，呃……不幸地发现了一大堆棘手的编译器错误。很多根源在于Yokeable<'a>在大多数情况下通过for<'a> Yokeable<'a>绑定（“对所有可能的生命周期'a的Yokeable<'a>”）。for<'a>是一个被称为高阶生命周期或trait绑定的 niche 特性（通常称为“HRTB”），虽然它一直是Rust类型系统能够推理函数指针所必需的，但它也一直相当有缺陷，并且经常不鼓励用于此类用途。

我们使用它是为了能够泛型地讨论一个类型的生命周期。幸运的是，有一个正在积极开发的语言特性将更适合此用途：泛型关联类型。

这个特性还不稳定，但幸运的是对于我们来说，大多数涉及for<'a>的编译器错误也会影响GAT，所以我们一直从GAT工作中受益，并且我们的很多错误报告帮助加强了GAT代码。非常感谢Jack Huey修复了很多这些错误，eddyb在调试过程中提供了帮助。

截至Rust 1.61，许多主要错误已得到修复，但仍然存在一些涉及trait绑定的错误，为此yoke crate维护了一些解决方法辅助工具。我们的经验是，这里的大多数编译器错误对于你可以使用这个crate做什么没有限制，但它们最终可能导致代码看起来不够理想。总的来说，我们仍然认为它是值得的，我们能够以对外部方便的方式做一些非常棒的零拷贝的事情（即使一些内部代码很乱），而且我们没有到处都是生命周期。

试用一下！

虽然我不认为yoke crate“完成”了，但它在ICU4X中已经使用了一年，我认为它已经足够成熟可以推荐给其他人。试用一下！让我知道你的想法！

感谢Finch、Jane和Shane审阅本文草稿

1. 区域设置通常是一个语言和位置，但它可能包含额外的信息，如书写系统甚至使用的日历系统等。↩

2. 请注意，这不仅仅是选择像MM-DD-YYYY这样的格式！仅在美国英语中，日期就可以是4/10/22或4/10/2022或April 10, 2022，或Sunday, April 10, 2022 C.E.，或Sun, Apr 10, 2022，这还不考虑周数、季度或时间！这很快就为每个区域设置增加到相当多的数据。↩

3. 这不是真实的Rust语法；因为Self总是Self，但我们需要能够将Self作为此场景中的高阶类型引用。↩

4. 不包括的类型是那些在生命周期周围涉及可变性（&mut或内部可变性）的类型，以及涉及函数指针和trait对象的类型。↩

由 mimo-v2.5 模型翻译，花费 26972 tokens

自从我开始在 Servo 的 JavaScript 层工作以来，我就一直在思考 Rust 中的垃圾回收（GC）。我曾 设计过一个 GC 库，研究过 Rust 本身的 GC 集成方案，参与过 Servo 的 JS GC 集成工作，并帮助过其他一些 Rust GC 项目，如 josephine 和 gc-arena。

因此，我经常被卷入 GC 讨论。我喜欢谈论 GC——别误会——但我经常需要重复讲解相同的内容。我比较懒，更希望能有一个地方，让人们可以快速了解 GC 设计的整体领域，然后再深入讨论特定设计的必要权衡。

我需要说明的是，本文中的一些 GC 实现是实验性的或未被维护。本文的目标是将它们作为 设计 示例进行展示，而不一定是你可以直接使用的通用 crate，尽管其中一些也是可用的 crate。

关于术语的说明

关于 GC 的讨论常常被混淆的一点是，根据某些“GC”的定义，简单的引用计数（Reference Counting）就是一种 GC。学术界通常使用的 GC 定义广泛指任何形式的自动内存管理。然而，大多数熟悉“GC”一词的程序员通常将其等同于“Java、Go、Haskell 和 C# 的做法”，这可以明确地称为追踪式（tracing）垃圾回收。

追踪式垃圾回收是指跟踪哪些堆对象是直接可达的（“根”），找出所有可达的堆对象集合（“追踪”，也称为“标记”），然后清理它们（“清除”）。

在整个博客文章中，除非另有说明，我将使用“GC”一词来指代追踪式垃圾回收/回收器¹。

为什么要在 Rust 中编写 GC？

（如果你已经想在 Rust 中编写 GC，并且阅读本文是为了获取如何实现的想法，你可以跳过这一节。你已经知道为什么有人会想为 Rust 编写 GC 了。）

每次这个话题被提起，总会有人说“我以为 Rust 的目的就是避免 GC”或“GC 会毁了 Rust”之类的。一般来说，不要过分在意评论区，但我认为解释一下为什么有人可能希望在 Rust 中获得类 GC 的语义是有用的。

真的有两种不同的使用场景。首先，有时你需要管理带有循环引用的数据，而 Rc<T> 不足以胜任，因为 Rc 循环会导致内存泄漏。petgraph 或内存池（arena）通常是处理这类模式的可接受方案，但并非总是如此，特别是当你的数据非常异构时。这类问题在处理并发数据结构时经常出现；例如 crossbeam 就有一个 基于纪元（epoch）的内存管理系统，虽然不是完整的追踪式 GC，但与 GC 有许多共同特征。

对于这种用例，很少需要设计自定义 GC，你可以寻找像 gc ² 这样的可复用 crate。

第二种情况，根据我的经验，远比第一种更有趣，并且由于无法用现成的解决方案解决，所以更常出现：与（或实现）确实使用垃圾回收器的编程语言进行集成。Servo 需要这样做来与 Spidermonkey JS 引擎集成，而 luster 需要这样做来实现其 Lua VM 的 GC。boa，一个纯 Rust JS 运行时，使用 gc crate 作为其垃圾回收器的后端。

有时在与使用 GC 的语言集成时，你可以避免实现完整的垃圾回收器：JNI 就是这样做的；虽然 C++ 本身没有原生的垃圾回收，但 JNI 通过简单地将任何跨越到 C++ 边界的对象进行“根化（rooting）”（我们稍后会介绍这是什么意思）来绕过这一点³。这通常没问题！

缺点是每次与 GC 管理的对象交互都必须通过 API 调用；你无法轻松地将高效的 Rust/C++ 对象“嵌入”到 GC 中。例如，在浏览器中，大多数 DOM 类型（例如 Element）都是用原生代码实现的；并且需要能够包含对其他原生 GC 类型的引用（应该可以在不需要回调 JavaScript 引擎的情况下检查 Node 的子节点）。

因此，有时你需要能够从运行时与 GC 集成；或者如果你正在编写一个需要 GC 的运行时，甚至需要实现自己的 GC。在这两种情况下，你通常希望能够从 Rust 代码中安全地操作 GC 管理的对象，甚至直接将 Rust 类型放在 GC 堆上。

为什么 Rust 中的 GC 很难实现？

用一个词来说：根化（Rooting）。在垃圾回收器中，栈上“直接”使用的对象是“根”，你需要能够识别它们。这里我说“直接”是指“无需通过其他 GC 对象就能访问”，所以将对象放入 Vec<T> 中并不会使其停止成为根，但放入其他 GC 对象中就会。

不幸的是，Rust 没有真正意义上的“直接在栈上”的概念：

struct Foo {
    bar: Option<Gc<Bar>>
}
// 这是一个根
let bar = Gc::new(Bar::new());
// 这也是一个根
let foo = Gc::new(Foo::new());
// bar 不应该再是根了（但我们无法检测到！）
foo.bar = Some(bar);
// 但 foo 在这里应该仍然是一个根，因为它没有在另一个 GC 对象内部
let v = vec![foo];

Rust 的所有权系统实际上使得更容易拥有较少的根，因为它相对容易说明获取 GC 对象的 &T 不需要创建新根，并让 Rust 的所有权系统来处理，但能够区分“直接拥有”和“间接拥有”是非常棘手的。

另一个方面是，垃圾回收实际上是一个全局变更的时刻——垃圾回收器遍历堆并删除其中的一些对象。这是脚底下的地毯被突然抽走的时刻。Rust 的整个设计都基于这种抽地毯行为是非常非常糟糕且不允许发生的，所以这可能会有点问题。这并不像最初听起来那么糟糕，毕竟抽地毯主要是清理不可达对象，但这在组装组件时确实会出现几次，尤其是在析构函数和终结器方面⁴。如果，例如，你能够声明“不会发生 GC”的代码区域⁵，那么根化将容易得多，这样你可以紧密地限定抽地毯的范围，而不必过多担心根。

析构函数与终结器

值得特别指出析构函数。在 GC 类型上自定义析构函数的一个巨大问题是，自定义析构函数完全可能在垃圾回收期间将自身存入一个长期存活的引用中，导致悬垂引用：

struct LongLived {
    dangle: RefCell<Option<Gc<CantKillMe>>>
}

struct CantKillMe {
    // 在构造时设置为指向自身
    self_ref: RefCell<Option<Gc<CantKillMe>>>
    long_lived: Gc<LongLived>
}

impl Drop for CantKillMe {
    fn drop(&mut self) {
        // 将自身附加到 long_lived
        *self.long_lived.dangle.borrow_mut() = Some(self.self_ref.borrow().clone().unwrap());
    }
}

let long = Gc::new(LongLived::new());
{
    let cant = Gc::new(CantKillMe::new());
    *cant.self_ref.borrow_mut() = Some(cant.clone());
    // cant 离开作用域，CantKillMe::drop 被运行
    // cant 被附加到 long_lived.dangle 但仍然被清理
}

// 悬垂引用！
let dangling = long.dangle.borrow().unwrap();

最常见的解决方案是禁止在使用 #[derive(Trace)] 的类型上使用析构函数，这可以通过让自定义 derive 生成一个 Drop 实现来实现，或者生成一些导致类型冲突错误的东西来实现。

你可以另外提供一个具有不同语义的 Finalize 特性：GC 在清理 GC 对象时调用它，但它可能被调用多次，也可能根本不被调用。这类事情在 Rust 之外的 GC 中也很常见。

没有运行时你如何进行垃圾回收？

在大多数带有垃圾回收的语言中，有一个运行时控制所有执行，知道程序中的每个变量，并且能够在任何时候暂停执行来运行 GC。

Rust 的运行时非常小，无法做到像这样，尤其是无法以你的库可以挂接的可插拔方式做到。对于线程本地 GC，你基本上必须编写代码，使得 GC 操作（如修改 GC 字段；基本上是你 GC 库暴露的 API 的某个子集）是唯一可能触发垃圾回收的操作。

并发 GC 可以在单独的线程上触发 GC，但通常需要在线程尝试执行可能被运行的垃圾回收器无效化的 GC 操作时暂停这些线程。

虽然这可能会限制垃圾回收器本身的灵活性，但从 API 设计的角度来看，这实际上对我们相当有利：垃圾回收阶段只能发生在代码的某些已知时刻，这意味着我们只需要确保这些边界上的事情是安全的。我们即将看到的许多设计都建立在这个观察的基础上。

共同点

在介绍实际的 GC 设计示例之前，我想指出它们在设计上的一些共同点，尤其是在它们如何进行追踪方面：

追踪

“追踪”是从你的根开始遍历 GC 对象图，查看它们的子对象，以及子对象的子对象，依此类推的操作。

在 Rust 中，实现此操作最简单的方法是通过自定义 derive：

// 手动实现是不安全的，因为你可能做错
unsafe trait Trace {
    fn trace(&mut self, gc_context: &mut GcContext);
}

#[derive(Trace)]
struct Foo {
    vec: Vec<Gc<Bar>>,
    extra_thing: Gc<Baz>,
    just_a_string: String
}

Trace 的自定义 derive 基本上只是在所有字段上调用 trace()。Vec 的 Trace 实现会调用其所有字段的 trace()，而 String 的 Trace 实现则什么都不做。Gc<T> 可能会有一个 trace() 方法，在 GcContext 中标记其可达性，或类似的操作。

这是一个相当标准的模式，虽然 Trace 特性的具体细节通常会有所不同，但大致思想是相似的。

我不会在这篇文章中深入讨论标记-清除算法如何工作的实际细节；它们有很多潜在的设计，并且从在 Rust 中设计安全的 GC API 的角度来看，它们并不是那么有趣。然而，一般的想法是维护一个最初由根填充的已发现对象队列，追踪它们以找到新对象，并在它们未被追踪过时将它们加入队列。清理任何未被发现的对象。

默认不可变

这些设计的另一个共同点是 Gc<T> 总是潜在共享的，因此需要对可变性进行严格控制以满足 Rust 的所有权不变式。这通常通过内部可变性（interior mutability）来实现，就像 Rc<T> 几乎总是与 RefCell<T> 配对用于可变访问一样，然而一些方法（如 josephine 中的方法）确实允许在没有运行时检查的情况下进行可变访问。

线程

有些 GC 是单线程的，有些是多线程的。单线程的 GC 通常有一个不是 Send 的 Gc<T> 类型，所以虽然你可以在不同的线程上设置多个 GC 类型的图，但它们本质上是独立的。垃圾回收只影响为其执行的线程，所有其他线程可以不受阻碍地继续运行。

多线程 GC 将有一个 Send 的 Gc<T> 类型。垃圾回收通常（但并非总是）会在该时间段内阻塞任何试图访问 GC 管理数据的线程。在某些语言中，有“停止世界（stop the world）”的垃圾回收器，它们在编译器插入的“安全点（safepoints）”阻塞所有线程；Rust 没有能力插入此类安全点，在 GC 上阻塞线程是在库层面完成的。

下面的大多数示例是单线程的，但它们的 API 设计不难扩展到假想的多线程 GC。

rust-gc

gc crate 是我与 Nika Layzell 一起编写的，主要是作为一个有趣的练习，以确定安全的 GC API 是否可能实现。我之前深入写过其设计，但其设计的本质是，它做了一些类似于引用计数的事情来跟踪根，并强制所有 GC 变更通过特殊的 GcCell 类型，以便它们可以更新根计数。基本上，每当某物成为根或停止成为根时，都会更新“根计数”：

struct Foo {
    bar: GcCell<Option<Gc<Bar>>>
}
// 这是一个根（根计数 = 1）
let bar = Gc::new(Bar::new());
// 这也是一个根（根计数 = 1）
let foo = Gc::new(Foo::new());
// .borrow_mut() 的 RAII guard 将 bar 根化（设置其根计数为 0）
*foo.bar.borrow_mut() = Some(bar);
// foo 在这里仍然是一个根，没有调用 .set()
let v = vec![foo];

// 在析构时，foo 的根计数被设置为 0

实际的垃圾回收阶段会在根据某些启发式方法认为堆已经变得足够大时，执行某些 GC 操作时发生。

虽然这对读取来说本质上是“免费”的，但这在任何类型的写操作上都产生了相当大的引用计数流量，这可能不是期望的；使用 GC 的目标通常是为了避免类似引用计数模式的性能特征。最终这是一种混合方法，结合了追踪和引用计数⁶。

gc 作为一个通用的 GC 是有用的，如果你只是希望一些东西参与循环而不需要思考太多。整体设计可以应用于与其他语言运行时集成的专用 GC，因为它提供了一种清晰的方式来跟踪根；但它可能不一定具有所需的性能特征。

Servo 的 DOM 集成

Servo 是一个用 Rust 编写的浏览器引擎，我曾经全职参与过。如前所述，浏览器引擎通常用原生代码（即 Rust 或 C++，而不是 JS）实现其大部分 DOM 类型，所以例如 Node 是一个纯 Rust 对象，并且它包含对其子节点的直接引用，这样 Rust 代码就可以进行遍历树等操作，而无需在 JS 和 Rust 之间来回切换。

Servo 的模型有点奇怪：根是不同的类型，并且 lint 会强制执行未根化的堆引用永远不会放在栈上：

#[dom_struct] // 这是 #[derive(JSTraceable)] 加上一些用于 lint 的标记
pub struct Node {
    // 父类型，用于继承
    eventtarget: EventTarget,
    // 在实际代码中，这是一个组合了 RefCell、Option 和 Dom 的不同辅助类型，但我为简化示例使用了 stdlib 类型
    prev_sibling: RefCell<Option<Dom<Node>>>,
    next_sibling: RefCell<Option<Dom<Node>>>,
    // ...
}

impl Node {
    fn frob_next_sibling(&self) {
        // 字段可以作为借用访问，无需任何根化
        if let Some(next) = self.next_sibling.borrow().as_ref() {
            next.frob();
        }
    }

    fn get_next_sibling(&self) -> Option<DomRoot<Node>> {
        // 但你需要将它们根化，以便它们能逃逸借用
        // .root() 将 Dom<T> 转换为 DomRoot<T>
        self.next_sibling.borrow().as_ref().map(|x| n.root())
    }

    fn illegal(&self) {
        // 这行代码会被一个名为 unrooted_must_root 的自定义 lint 检查
        // （它的工作方式类似于 Rust 的 must_use）
        let ohno: Dom<Node> = self.next_sibling.borrow_mut().take();
    }
}

Dom<T> 基本上是一个智能指针，行为像 &T 但没有生命周期，而 DomRoot<T> 具有创建时根化（并在 Drop 时取消根化）的附加行为。自定义 lint 插件本质上强制执行 Dom<T>，以及任何 DOM 结构体（用 #[dom_struct] 标记），除了通过 DomRoot<T> 或 &T，否则永远无法在栈上访问。

我不推荐这种方法；它工作得还好，但我们早就想摆脱它了，因为它依赖于自定义插件 lint 来保证健全性。但为了完整性，值得一提。

Josephine（Servo 的实验性 GC 方案）

鉴于 Servo 现有的 GC 解决方案依赖于编译器进行额外的静态分析，我们想要更好的方案。因此 Alan 设计了 Josephine（“JS 仿射”），它更干净地使用 Rust 的仿射类型和借用（borrowing）来提供一个安全的 GC 系统。

Josephine 是专门为 Servo 的用例设计的，因此它围绕“区域（compartments）”等做了很多巧妙的事情，除非你特别希望你的 GC 与 JS 引擎集成，否则这些可能无关紧要。

我前面提到过，垃圾回收阶段只能发生在代码的某些已知时刻，这实际上可以使 GC 设计更容易，而 Josephine 就是这样一个例子。

Josephine 有一个“JS 上下文（JS context）”，它需要在各处传递，本质上代表 GC 本身。当执行可能触发 GC 的操作时，你必须可变地借用上下文，而当访问堆对象时，你需要不可变地借用上下文。你可以根化堆对象以消除这个要求：

// cx 是一个 `JSContext`，`node` 是一个 `JSManaged<'a, C, Node>`
// 为简化起见，假设 next_sibling 和 prev_sibling 不是 Option

// 为 `'b` 借用 cx
let next_sibling: &'b Node = node.next_sibling.borrow(cx);
println!("Name: {:?}", next_sibling.name);
// 非法，因为 cx 被 next_sibling 不可变地借用了
// node.prev_sibling.borrow_mut(cx).frob();

// 从 next_sibling 读取以确保它存活足够长
println!("{:?}", next_sibling.name);

let ref mut root = cx.new_root();
// 不再需要借用 cx，而是借用 root 持续时间为 'root
let next_sibling: JSManaged<'root, C, Node> = node.next_sibling.in_root(root);
// 现在没问题了，`cx` 没有未解决的借用
node.prev_sibling.borrow_mut(cx).frob();

// 从 next_sibling 读取以确保它存活足够长
println!("{:?}", next_sibling.name);

new_root() 创建一个新的根，而 in_root 将 JS 托管类型的生命周期绑定到根而不是 JSContext 借用，释放了 JSContext 的借用，允许在未来 .borrow_mut() 调用中可变借用。

请注意，这里的 .borrow() 和 .borrow_mut() 尽管与 RefCell::borrow() 相似，但没有运行时借用检查成本；它们反而进行了一些生命周期变换（juggling）以确保安全。创建根通常确实有运行时成本。有时你可能需要使用 RefCell<T>，原因与在 Rc 中使用相同，但大多仅用于非 GC 字段。

自定义类型通常这样定义为两部分：

#[derive(Copy, Clone, Debug, Eq, PartialEq, JSTraceable, JSLifetime, JSCompartmental)]
pub struct Element<'a, C> (pub JSManaged<'a, C, NativeElement<'a, C>>);

#[derive(JSTraceable, JSLifetime, JSCompartmental)]
pub struct NativeElement<'a, C> {
    name: JSString<'a, C>,
    parent: Option<Element<'a, C>>,
    children: Vec<Element<'a, C>>,
}

其中 Element<'a> 是一个方便的可复制引用，用于其他 GC 类型内部，而 NativeElement<'a> 是其后备存储。C 参数与区域有关，现在可以忽略。

值得一提的一个巧妙之处是，即使根允许你持有对同一对象的多个引用，操作其他 GC 引用也不需要运行时借用检查！

let parent_root = cx.new_root();
let parent = element.borrow(cx).parent.in_root(parent_root);
let ref mut child_root = cx.new_root();

// 可能是 `element` 的第二个引用，如果它是第一个子节点的话
let first_child = parent.children[0].in_root(child_root);

// 这没问题，即使我们通过 element.parent 持有对 `parent` 的引用
// 因为我们已经根化了该引用，所以它现在独立于 `element.parent` 是否更改！
first_child.borrow_mut(cx).parent = None;

本质上，当修改字段时，你必须获得对上下文的可变访问权，因此字段本身不会有仍然存在的引用（例如 element.borrow(cx).parent），只有对其内部的 GC 数据的引用，所以你可以更改字段引用的内容而不会使其他对字段引用的内容的引用失效。这是一个非常巧妙的技巧，实现了没有运行时检查的内部可变性的 GC，这在类似的设计中相对罕见。

Rust 内置 GC 的未完成设计

有一段时间，我们几个人研究了一种使 Rust 本身 可扩展并支持可插拔 GC 的方法，利用 LLVM 栈映射（stack map）支持来查找根。毕竟，如果我们知道哪些类型是 GC 类的，我们就可以为每个函数包含如何查找根的元数据，类似于 Rust 函数当前包含的展开（unwinding）钩子，以便在 panic 期间干净地运行析构函数。

我们从未完成设计，但你可以在我和Felix关于这个主题的文章中找到更多信息。本质上，它涉及一个具有更通用 trace 方法的 Trace 特性，一个自动实现的 Root 特性（其工作方式类似于 Send），以及编译器机制来跟踪哪些 Root 类型在栈上。

这对于试图实现 GC 的人可能不太有用，但我为了完整性而提及它。

请注意，1.0 之前的 Rust 确实有一个内置的 GC（@T，被称为“托管指针”），但据我回忆，实际上循环管理部分从未被实现，所以它表现得完全像 Rc<T>。我相信它本意是要有一个循环收集器（我将在下一节讨论更多）。

bacon-rajan-cc（以及一般的循环收集器）

Nick Fitzgerald 编写了 bacon-rajan-cc 来实现 David F. Bacon 和 V.T. Rajan 的论文 "Concurrent Cycle Collection in Reference Counted Systems"。

这就是俗称的循环收集器（cycle collector）；一种垃圾回收器，本质上可以理解为“如果我们拿了 Rc<T> 但让它能检测循环引用会怎样”。有些人不认为这些是追踪式垃圾回收器，但它们有很多类似的特征（并且它们确实仍然“追踪”类型）。它们通常被归类为“混合”方法，就像 gc 一样。

其思想是，如果你维护引用计数，你实际上不需要知道根是什么：如果一个堆对象的引用计数多于引用它的堆对象数量，那么它一定是一个根。实际上，遍历整个堆效率很低，因此会应用优化，通常是通过给节点分配不同的“颜色”，并且只查看最近其引用计数递减的对象集合。

这里一个关键的观察是，如果你只关注潜在的垃圾，你可以稍微调整你对“根”的定义，在寻找循环引用时，你不需要寻找来自栈的引用，你可以满足于来自你确切知道可以从非潜在垃圾对象可达的堆的任何部分的引用。

循环收集器的一个巧妙特性是，虽然标记-清除追踪式 GC 的性能随整个堆的大小而变化，但循环收集器的性能随你拥有的实际垃圾的大小而变化⁷。当然还有其他权衡：在追踪式 GC 中，释放通常更便宜或“免费”（通过在清除阶段摊销这些成本），而循环收集器在引用计数归零时清理对象涉及恒定的分配器流量。

bacon-rajan-cc 的工作方式是，每次引用计数递减时，该对象都会被添加到“潜在循环根”列表中，除非引用计数递减到 0（在这种情况下，对象会立即被清理，就像 Rc 一样）。然后它追踪这个列表；对于它跟随的每个引用递减引用计数，并清理任何引用计数达到 0 的元素。然后它再次遍历这个列表，并对它跟随的每个引用递增引用计数，以恢复原始的引用计数。这基本上将任何不能从这个“潜在循环根”列表可达的元素视为“非垃圾”，并且不去访问它。

循环收集器需要对垃圾回收算法进行更紧密的控制，并且具有不同的性能特征，因此它们不一定适用于 Rust 中 GC 集成的所有用例，但绝对值得考虑！

cell-gc

Jason Orendorff 的 cell-gc crate 很有趣，它有一个“堆会话（heap sessions）”的概念。这是自定义 readme 的一个修改示例：

use cell_gc::Heap;

// 实现 IntoHeap，并生成一个 IntListRef 类型和访问器
#[derive(cell_gc_derive::IntoHeap)]
struct IntList<'h> {
    head: i64,
    tail: Option<IntListRef<'h>>
}

fn main() {
    // 创建一个堆（你整个程序只做一次）
    let mut heap = Heap::new();

    heap.enter(|hs| {
        // 分配一个对象（返回一个 IntListRef）
        let obj1 = hs.alloc(IntList { head: 17, tail: None });
        assert_eq!(obj1.head(), 17);
        assert_eq!(obj1.tail(), None);

        // 分配另一个对象
        let obj2 = hs.alloc(IntList { head: 33, tail: Some(obj1) });
        assert_eq!(obj2.head(), 33);
        assert_eq!(obj2.tail().unwrap().head(), 17);

        // 修改 `tail`
        obj2.set_tail(None);
    });
}

所有修改都通过自动生成的访问器进行，因此该 crate 对通过 GC 的流量有更多控制。这些访问器通过类似于 gc 所做方案的方案帮助跟踪根；其中使用 IntoHeap 特性在引用通过访问器放入和取出堆时修改根引用计数。

堆会话允许堆被移动，甚至发送到其他线程，它们的生命周期防止堆对象在会话之间混合。这使用了一个称为世代性（generativity）的概念；你可以在Aria Beingessner 的《You Can't Spell Trust Without Rust》第 6.3 章，或通过查看 indexing crate 来了解更多关于世代性的信息。

幕间：async 与 GC 的相似性

接下来的两个示例使用 Rust 的 async 功能的机制，尽管与 async I/O 无关，我认为解释一下为什么这是合理的很重要。我之前发过推文：Catherine West 和我是在讨论她基于 async 的GC 想法时发现这一点的。

你可以在 Go 中看到这种对应性：Go 是一种同时具有垃圾回收和 async I/O 的语言，两者都使用相同的“安全点”让出给垃圾回收器或调度器。在 Go 中，编译器需要自动插入代码来检查堆的“脉搏”，并可能运行垃圾回收。它还需要自动插入代码来告诉调度器“嘿，现在是让我安全中断的好时机，如果另一个 goroutine 想要运行的话”。这些在原理上非常相似——它们本质上都是编译器插入的“现在可以中断我”的检查点，有时称为“中断点”或“让出点（yield points）”。

现在，Rust 编译器不会自动插入中断点。然而，Rust 中 async 的设计本质上是一种向 Rust 添加显式中断点的方式。Rust 中的 foo().await 是运行 foo() 并期望调度器可能在两者之间中断代码的方式。Future 和 Pin<P> 的设计是为了使这既安全又令人愉快。

正如我们将看到的，相同的机制可用于在 Rust 中为 GC 创建安全的中断点。

Shifgrethor

shifgrethor 是 Saoirse 的一个实验，尝试构建一个使用 Pin<P> 来管理根的 GC。他们已经写了大量关于 shifgrethor 设计的博客文章。特别是，关于根化的文章详细介绍了根化是如何工作的。

基本设计是有一个 Root<'root> 类型，其中包含一个 Pin<P>

由 mimo-v2.5 模型翻译，花费 38191 tokens

最近关于Rust中的Arena有一些讨论，我想就这个话题写点东西。

Arena并不是Rust中你通常会首先想到的东西，因此了解它的人较少；你通常只会在某些特定应用场景中看到它。通常，你可以通过引入一个crate来使用Arena，而无需额外使用unsafe，所以在Rust中不必对它特别担忧，而且了解它似乎很有用，特别是对于从Arena更常见的领域转向Rust的人来说。

此外，当实现自引用Arena时，涉及一系列非常酷的生命周期效应，我认为之前还没有人写过相关内容。

我写这篇文章主要是为了探讨那些酷的生命周期效应，但我觉得值得写一个对所有Rust程序员都有价值的通用介绍。如果你知道Arena是什么，只想了解酷的生命周期效应，可以直接跳到实现自引用Arena的部分。否则，请继续阅读。

什么是Arena？

Arena本质上是一种将预期具有相同生命周期的分配分组的方法。有时你需要为一个事件的生命周期分配一批对象，之后可以将它们全部丢弃。每次都调用系统分配器效率低下，更可取的做法是为你的对象预分配一批内存，在完成后一次性清理。

广泛来说，你可能希望使用Arena有两个原因：

首先，如前所述，你的主要目标可能是减少分配压力。例如，在游戏或应用程序中，可能有大量每帧需要分配然后丢弃的每帧对象。这在游戏开发中尤为常见，游戏开发者往往很关心分配器压力。使用Arena，可以轻松分配一个Arena，在每帧填充它，然后在帧结束后清理它。这还有缓存局部性的额外好处：你可以确保大多数每帧对象（可能比其他对象更频繁使用）在帧期间通常位于缓存中，因为它们是相邻分配的。

另一个目标可能是你想编写自引用数据，比如一个可以一次性清理的复杂带循环图。例如，在编写编译器时，类型信息可能需要引用其他类型和其他数据，导致一个复杂的、可能是循环的类型图。一旦你计算了一个类型，你可能不需要单独丢弃它，所以你可以使用一个Arena来存储所有计算出的类型信息，在类型不再重要的阶段一次性清理所有内容。使用这种模式可以让你的代码不必担心自引用部分是否会被“提前”释放，它让你可以假设如果你有一个Ty，它的生命周期与所有其他Ty相同，并且可以直接引用它们。

这两个目标不一定互斥：你可能希望使用Arena同时实现这两个目标。但你也可以有一个不允许自引用类型的Arena（但具有其他良好特性）。在本文的后面，我将实现一个允许自引用类型但在分配压力方面不理想的Arena，主要是为了便于实现。通常如果你为自引用类型编写Arena，你可以让它同时减少分配器压力，但也可能存在权衡。

如何在Rust中使用Arena？

通常，要使用Arena，你只需引入一个实现了正确类型Arena的crate。我知道有两个，下面会讨论，不过在crates.io上快速搜索“arena”会发现许多其他有前途的候选者。

我要指出的是，如果你只需要循环图结构，你不一定必须使用Arena，优秀的petgraph crate通常就足够了。slotmap也很有用；它是一个基于代际索引的映射式数据结构，适用于自引用数据。

Bumpalo

Bumpalo是一个快速的“凸分配器”，允许异构内容，只有在你不在乎析构函数运行的情况下才允许循环。

use bumpalo::Bump;

// (示例略作修改自 `bumpalo` 文档)

// 创建一个用于凸分配的新 Arena。
let bump = Bump::new();

// 在 Arena 中分配值。
let scooter = bump.alloc(Doggo {
    cuteness: u64::max_value(),
    age: 8,
    scritches_required: true,
});

// 生日快乐，Scooter！
scooter.age += 1;

每次调用Bump::alloc()都会返回一个指向已分配对象的可变引用。你可以分配不同的对象，它们甚至可以相互引用¹。默认情况下，它不会对其内容调用析构函数；但是，你可以使用bumpalo::boxed（或Nightly版的自定义分配器）来获得此行为。类似地，你可以使用bumpalo::collections来获得由bumpalo支持的向量和字符串。bumpalo::boxed将不被允许参与循环。

typed-arena

typed-arena是一个只能存储单一类型对象的Arena分配器，但它允许建立循环引用：

// 来自 typed-arena 文档的示例

use std::cell::Cell;
use typed_arena::Arena;

struct CycleParticipant<'a> {
    other: Cell<Option<&'a CycleParticipant<'a>>>,
}

let arena = Arena::new();

let a = arena.alloc(CycleParticipant { other: Cell::new(None) });
let b = arena.alloc(CycleParticipant { other: Cell::new(None) });

// 事后进行变异以设置循环
a.other.set(Some(b));
b.other.set(Some(a));

与bumpalo不同，typed-arena在Arena本身离开作用域时总会对其内容运行析构函数²。

实现一个自引用Arena

自引用Arena之所以有趣，是因为通常Rust对自引用数据非常非常警惕。但Arena允许你清晰地分离“我不关心这个对象”和“这个对象可以被删除”这两个步骤，这足以允许自引用和循环类型。

需要自己实现Arena的情况相当罕见——bumpalo和typed-arena涵盖了大多数用例，如果它们没有覆盖你的用例，你很可能在crates.io上找到合适的东西。但如果你确实需要，或者你对底层的生命周期细节感兴趣，这一节适合你。

实现一个条目类型为Entry的Arena Arena的关键在于以下规则：

• Arena和Entry都应该有一个生命周期参数：Arena<'arena>和Entry<'arena>
• Arena的所有方法都应该接收Arena<'arena>作为&'arena self，即它们的self类型是&'arena Arena<'arena>
• Entry几乎总是应该作为&'arena Entry<'arena>传递（为此定义一个别名很有用）
• 使用内部可变性；Arena上的&mut self会使所有东西停止编译。如果使用unsafe进行可变操作，请确保在某个地方有PhantomData用于RefCell<Entry<'arena>>。

以上基本上是生命周期方面的全部要求，其余工作都在确定你想要的API和实现后备存储。有了上述规则，你应该能够让你的自定义Arena按你需要的保证工作，而不必理解底层生命周期发生了什么。

让我们通过一个实现示例，然后剖析为什么它有效。

实现

我的crate elsa在其一个示例中以100%安全代码实现了一个Arena。这个Arena并不节省分配，因为elsa::FrozenVec要求其内容位于某种间接引用之后，并且它不是泛型的，但它是说明生命周期如何工作的一种合理方式，而不会陷入实现一个非常优秀的Arena所需的unsafe细节。

该示例实现了一个Person<'arena>类型的Arena，Arena<'arena>。目标是实现某种有向社交图，它可能有循环。

use elsa::FrozenVec;

struct Arena<'arena> {
    people: FrozenVec<Box<Person<'arena>>>,
}

elsa::FrozenVec是一个仅追加的Vec式抽象，允许你在不需要可变引用的情况下调用.push()，这就是我们能够在安全代码中实现这个Arena的原因。

每个Person<'arena>都有一个他们关注的人列表，但也跟踪关注他们的人：

struct Person<'arena> {
    pub follows: FrozenVec<PersonRef<'arena>>,
    pub reverse_follows: FrozenVec<PersonRef<'arena>>,
    pub name: &'static str,
}

// 遵循上面关于条目类型引用的规则
type PersonRef<'arena> = &'arena Person<'arena>;

生命周期'arena本质上是“Arena本身的生命周期”。这就是奇怪的地方开始出现：通常，如果你的类型有一个生命周期参数，调用者可以选择填入什么。你不能仅仅说“这是对象本身的生命周期”，调用者通常能够实例化一个Arena<'static>，或者一个Arena<'a>（某个'a）。但这里我们声明'arena是Arena本身的生命周期；显然这里有些不对劲。

以下是我们实际实现Arena的地方：

impl<'arena> Arena<'arena> {
    fn new() -> Arena<'arena> {
        Arena {
            people: FrozenVec::new(),
        }
    }
    
    fn add_person(&'arena self, name: &'static str,
                  follows: Vec<PersonRef<'arena>>) -> PersonRef<'arena> {
        let idx = self.people.len();
        self.people.push(Box::new(Person {
            name,
            follows: follows.into(),
            reverse_follows: Default::default(),
        }));
        let me = &self.people[idx];
        for friend in &me.follows {
            // 我们正在变异现有的 Arena 条目以添加引用，
            // 可能创建循环！
            friend.reverse_follows.push(me)
        }
        me
    }

    fn dump(&'arena self) {
        // 打印每个 Person、他们的关注者以及关注他们的人的代码
    }
}

注意add_person中的&'arena self。

这里一个好的实现通常会分离出处理“如果Afollows B，那么Breverse_follows A”这个高层不变量的代码，但这只是一个示例。

最后，我们可以这样使用Arena：

fn main() {
    let arena = Arena::new();
    let lonely = arena.add_person("lonely", vec![]);
    let best_friend = arena.add_person("best friend", vec![lonely]);
    let threes_a_crowd = arena.add_person("threes a crowd", vec![lonely, best_friend]);
    let rando = arena.add_person("rando", vec![]);
    let _everyone = arena.add_person("follows everyone", vec![rando, threes_a_crowd, lonely, best_friend]);
    arena.dump();
}

在这种情况下，所有“可变性”都发生在Arena本身的实现中，但此代码直接向follows/reverse_follows列表添加条目是可能的，或者Person可以为其他类型的链接拥有RefCell，或者任何其他方式。

生命周期如何工作

那么这是如何工作的呢？正如我之前所说，对于Rust中的此类抽象，调用者通常可以自由地根据他们如何使用它来设置生命周期。例如，如果你有一个HashMap<K, &'a str>，'a将基于你尝试插入的内容的生命周期来设置。

当你构造Arena时，其生命周期参数确实是无约束的，我们可以通过检查以下代码（它强制约束了生命周期）仍然编译来测试这一点。

let arena: Arena<static> = Arena::new();

但一旦你尝试对Arena做任何事情，这就行不通了：

let arena: Arena<static> = Arena::new();
let lonely = arena.add_person("lonely", vec![]);

error[E0597]: `arena` does not live long enough
  --> examples/mutable_arena.rs:5:18
   |
4  |     let arena: Arena<'static> = Arena::new();
   |                -------------- type annotation requires that `arena` is borrowed for `'static`
5  |     let lonely = arena.add_person("lonely", vec![]);
   |                  ^^^^^ borrowed value does not live long enough
...
11 | }
   | - `arena` dropped here while still borrowed

add_person方法不知何故突然强制Arena的'arena参数设置为它自己的生命周期，约束它（并且使得用类型注解强制将其约束为其他值变得不可能）。

这里发生的事情是add_person的&'arena self签名（即self是&'arena Arena<'self>）与Arena<'arena>中'arena是一个不变生命周期的事实之间的巧妙交互。

通常在你的Rust程序中，生命周期有点可伸可缩。以下代码编译得很好：

// 请求两个具有*相同生命周期*的字符串
fn take_strings<'a>(x: &'a str, y: &'a str) {}

// 具有生命周期 'static 的字符串字面量
let lives_forever = "foo";
// 具有较短局部生命周期的所有权字符串
let short_lived = String::from("bar");

// 仍然有效！
take_strings(lives_forever, &*short_lived);

在这段代码中，Rust很乐意注意到虽然lives_forever和&*short_lived具有不同的生命周期，但在take_strings函数的持续时间内，完全可以假装lives_forever具有较短的生命周期。它只是一个引用，一个具有较长生命周期的引用也对较短生命周期有效。

问题是，这种可伸可缩性并非对所有生命周期都相同！nomicon中关于子类型和变体的章节详细解释了为什么是这种情况，但一个通用经验法则是，大多数生命周期是“可缩的”³，如上面&'a str中的那个，但如果涉及某种形式的可变性，它们就是刚性的，也称为“不变”。如果你使用函数类型，也可以有“可伸的”⁴生命周期，但它们很少见。

我们的Arena<'arena>以一种使'arena不变的方式使用内部可变性（通过FrozenVec）。

让我们再次看看我们的两行代码。当编译器看到下面代码的第一行时，它构造了arena，我们将其生命周期称为'a。此时，arena的类型是Arena<'?>，其中'?是我们为尚未约束的生命周期编造的表示法。

let arena = Arena::new(); 
let lonely = arena.add_person("lonely", vec![]);

让我们实际上重写它以更清楚地说明生命周期是什么。

let arena = Arena::new(); // 类型 Arena<'?>，生命周期为 'a

// 显式写出调用 add_person 时构造的 `self`
let ref_to_arena = &arena; // 类型 &'a Arena<'?>
let lonely = Arena::add_person(ref_to_arena, "lonely", vec![]);

还记得我之前列出的第二条规则吗？

Arena的所有方法都应该接收Arena<'arena>作为&'arena self，即它们的self类型是&'arena Arena<'arena>

我们遵循了这个规则；add_person的签名是fn add_person(&'arena self)。这意味着ref_to_arena被强制具有匹配模式&'arena Arena<'arena>的生命周期。目前它的生命周期是&'a Arena<'?>，这意味着'?被强制与'a相同，即arena变量本身的生命周期。如果生命周期不是不变的，编译器将能够挤压其他生命周期以适应，但它是不变的，并且无约束的生命周期被强制恰好是一个生命周期。

通过这个相当微妙的戏法，我们能够强制编译器将Arena<'arena>的参数化生命周期设置为其实例的生命周期。

此后，其余部分就相当简单了。Arena<'arena>持有Person<'arena>类型的条目，这基本上是一种说法，即“一个被允许引用生命周期为'arena的项目的Person，即Arena中的项目”。type PersonRef<'arena> = &'arena Person<'arena>是一个便捷的简写，表示“一个存在于Arena中并被允许引用其对象的Person的引用”。

析构函数怎么办？

到目前为止，我还没有涉及的一件事是，在存在析构函数的情况下这如何能是安全的。如果你的Arena被允许有循环引用，并且你编写一个从这些循环引用读取的析构函数，那么在循环中稍后删除的任何一个参与者都会具有悬垂引用。

这涉及到Rust中一个非常晦涩的部分，甚至比变体更晦涩。你几乎不需要真正理解这一点，除了“显式析构函数会微妙地改变借用检查行为”。但了解它对于更好地理解这里发生的事情很有用。

如果我们向Arena示例添加以下代码：

impl<'arena> Drop for Person<'arena> {
    fn drop(&mut self) {
        println!("goodbye {:?}", self.name);
        for friend in &self.reverse_follows {
            // 可能悬垂！
            println!("\t\t{}", friend.name);
        }
    }
}

我们实际上会得到这个错误：

error[E0597]: `arena` does not live long enough
  --> examples/mutable_arena.rs:5:18
   |
5  |     let lonely = arena.add_person("lonely", vec![]);
   |                  ^^^^^ borrowed value does not live long enough
...
11 | }
   | -
   | |
   | `arena` dropped here while still borrowed
   | borrow might be used here, when `arena` is dropped and runs the destructor for type `Arena<'_>`

析构函数的存在微妙地改变了借用检查器在自引用生命周期周围的行为。确切的规则很棘手，在nomicon中有解释，但本质上发生的是，Person<'arena>上的自定义析构函数的存在使得Person（以及Arena）中的'arena成为一个“在析构过程中被观察到”的生命周期。这在借用检查中被考虑在内——突然间，作用域末尾的隐式drop()被知道能够读取'arena数据，Rust得出了适当的结论：在内容被清理后，drop()将能够读取事物，因为析构本身是一个可变操作，而drop()是在其中交错运行的。

当然，一个合理的问题是，如果析构函数不被允许“包装”带有'arena的类型，我们如何存储像Box和FrozenVec这样的东西。原因是Rust知道Box上的Drop不能检查person.follows，因为Box甚至不知道什么是Person，并且已经承诺永远不会试图去了解。如果我们有一个随机泛型类型，这不一定是真的，因为析构函数可以调用特征方法（或特化的覆盖方法），这些方法确实知道如何读取Person的内容，但在这种情况下，微妙改变的借用检查器规则会再次发挥作用。标准库类型和其他自定义数据结构通过一个逃生舱口实现这一点，#[may_dangle]（也称为“眼罩”⁵），它允许你保证不会在自定义析构函数中读取生命周期或泛型参数。

这同样适用于typed-arena等crate；如果你正在创建循环，你将无法在放入Arena的类型上编写自定义析构函数。只要你不以可以创建循环的方式进行变异，你可以使用typed-arena编写自定义析构函数；所以你将无法使用内部可变性让一个Arena条目指向另一个。

感谢Mark Cohen和Nika Layzell审阅了本文的草稿。

由 mimo-v2.5 模型翻译，花费 28341 tokens