计算机科学 on InfyniteHeap's Personal Blog

LRU 和 LFU 笔记

Sat, 09 Aug 2025 07:30:16 +0800

近日，笔者在 LeetCode 上刷到了146. LRU 缓存和460. LFU 缓存这两道题。虽然这两种数据结构工作原理不难理解，但是实现它们却并非易事。因此，笔者撰写本篇文章，旨在带领读者自下至上逐步实现这两种数据结构。

至于 LRU 和 LFU 的概念与工作原理，网上都有，这里便不再单独讲解了。

说明

LRU 和 LFU 的核心是链式哈希表。该数据结构有如下特点：

保证内部元素的插入顺序。
增删查改操作的时间复杂度均为 O(1)，且不会破坏原有元素插入顺序。

部分编程语言已经内置了这种数据结构，允许开发者直接使用：

Java：LinkedHashMap。
Python：自 3.7 版本起，Python 内置的dict便已符合上述特点。当然，考虑到我们有将数据移动到双向链表头/尾的需求，我们一般会使用collections.OrderedDict，因为它包含诸如move_to_end等这样方便的高级方法。
JavaScript/TypeScript：Map。

以 Python 为例，LRU 实现如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


from collections import OrderedDict


class LRUCache:
 # 使用__slots__属性以提高访问类内属性的速度
 __slots__: list[str] = ["cache", "cap"]

 def __init__(self, capacity: int) -> None:
 # 显式标注类型可提升代码可读性，以及开发时的code lint体验
 self.cache: OrderedDict[int, int] = OrderedDict()
 self.cap: int = capacity

 def get(self, key: int) -> int:
 if key not in self.cache:
 return -1

 self.cache.move_to_end(key, last=False)
 return self.cache[key]

 def put(self, key: int, value: int) -> None:
 if self.cap == 0:
 return

 self.cache[key] = value
 self.cache.move_to_end(key, last=False)

 if len(self.cache) > self.cap:
 _ = self.cache.popitem()

LFU 实现如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69


from collections import OrderedDict


class LFUCache:
 __slots__: list[str] = [
 "key_to_value",
 "key_to_freq",
 "freq_to_keys",
 "min_freq",
 "cap",
 ]

 def __init__(self, capacity: int) -> None:
 self.key_to_value: dict[int, int] = {}
 self.key_to_freq: dict[int, int] = {}
 self.freq_to_keys: dict[int, OrderedDict[int, None]] = {}
 self.min_freq: int = 0
 self.cap: int = capacity

 def increase_freq(self, key: int) -> None:
 freq = self.key_to_freq[key]
 self.key_to_freq[key] += 1

 del self.freq_to_keys[freq][key]
 if len(self.freq_to_keys[freq]) == 0:
 del self.freq_to_keys[freq]
 if freq == self.min_freq:
 self.min_freq += 1

 if freq + 1 not in self.freq_to_keys:
 self.freq_to_keys[freq + 1] = OrderedDict()
 self.freq_to_keys[freq + 1][key] = None

 def remove_min_freq_key(self) -> None:
 key, _ = self.freq_to_keys[self.min_freq].popitem(last=False)

 if len(self.freq_to_keys[self.min_freq]) == 0:
 del self.freq_to_keys[self.min_freq]

 del self.key_to_value[key]
 del self.key_to_freq[key]

 def get(self, key: int) -> int:
 if key not in self.key_to_value:
 return -1

 self.increase_freq(key)
 return self.key_to_value[key]

 def put(self, key: int, value: int) -> None:
 if self.cap == 0:
 return

 if key in self.key_to_value:
 self.key_to_value[key] = value
 self.increase_freq(key)

 return

 self.key_to_value[key] = value
 self.key_to_freq[key] = 1
 if 1 not in self.freq_to_keys:
 self.freq_to_keys[1] = OrderedDict()
 self.freq_to_keys[1][key] = None

 if len(self.key_to_value) > self.cap:
 self.remove_min_freq_key()

 self.min_freq = 1

部分编程语言或许没有内置链式哈希表，但允许开发者利用语言内置的双向链表和哈希表手动实现一个¹：

C++：std::list和std::unordered_map。其中，哈希表的值是指向与键相关的双向链表节点的迭代器（本质上就是指针）。
Go：list和map。其中，哈希表的值是指向与键相关的双向链表节点的指针，其类型为*list.Element。
.NET²：LinkedList和Dictionary。其中，哈希表的值是指向与键相关的双向链表节点的指针，其类型为LinkedListNode。

除上述语言外，其余语言除了要手动实现链式哈希表，还要在实现它之前先手动实现一个双向链表！综合考虑，本文将给出 Rust 代码实现。除了 Rust（很不幸）不符合上述两种情况³之外，还有以下这些原因：

笔者最熟悉的语言是 Rust。
Rust 对类型的要求非常严格，且不允许隐式类型转换。
由于 Rust 严格限制裸指针的使用⁴，因此使用 Rust 编写链式数据结构要比其他语言困难。譬如，要表示指向某对象的指针，其他语言要么使用*Type或Type*，要么把类规定为引用类型（通常这种情况发生在 GC 语言中，因为这类语言往往按引用传递类对象）。而 Rust 则一般使用Option<Rc<RefCell<Node<E>>>>来表示。访问对象时，其他语言可以直接使用ptr->field（C/C++）或ptr.field，而 Rust 则必须用ptr.as_ref().unwrap().borrow().field。其中，使用as_ref()是为了防止unwrap将ptr的所有权转移走，以方便后续继续使用ptr。

接下来，我们开始使用 Rust 逐步实现 LRU 和 LFU！

实现双向链表

根据上述所言，我们需要先实现双向链表。我们将实现步骤拆为两步：

实现双向链表节点。
实现双向链表本身。

实现双向链表节点

首先，我们先来实现双向链表节点：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


use std::cell::RefCell;
use std::rc::Rc;

#[derive(PartialEq, Eq)]
struct Node<E> {
 prev: Option<Rc<RefCell<Node<E>>>>,
 next: Option<Rc<RefCell<Node<E>>>>,
 element: E,
}

impl<E> Node<E>
where
 E: PartialEq + Eq,
{
 fn new(element: E) -> Self {
 Self {
 prev: None,
 next: None,
 element,
 }
 }
}

我们为节点定义三个字段：用于指向前一个节点的prev、用于指向后一个节点的next，以及用于存储数据的element。其中，element为任意类型的数据，因此我们将其类型设为泛型类型。

实现双向链表

有了前面实现的双向链表节点，我们就可以实现双向链表了。

首先，我们先实现其数据结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


struct DoubleLinkedList<E> {
 head: Option<Rc<RefCell<Node<E>>>>,
 tail: Option<Rc<RefCell<Node<E>>>>,
 len: usize,
}

impl<E> DoubleLinkedList<E>
where
 E: Default + PartialEq + Eq,
{
 fn new() -> Self {
 let head = Some(Rc::new(RefCell::new(Node::new(E::default()))));
 let tail = Some(Rc::new(RefCell::new(Node::new(E::default()))));

 head.as_ref().unwrap().borrow_mut().next = tail.clone();
 tail.as_ref().unwrap().borrow_mut().prev = head.clone();

 Self { head, tail, len: 0 }
 }
}

我们为双向链表定义三个字段：head、tail和len。其中，head和tail表示虚拟空节点，用于方便处理移除头/尾节点的情况；len表示双向链表长度，即双向链表所包含的节点数量。

接下来，我们为双向链表添加一些方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96


fn push_front(&mut self, node: Option<Rc<RefCell<Node<E>>>>) {
 if node.is_none() {
 return;
 }

 node.as_ref().unwrap().borrow_mut().prev = self.head.clone();
 node.as_ref().unwrap().borrow_mut().next = self.head.as_ref().unwrap().borrow().next.clone();

 self.head
 .as_ref()
 .unwrap()
 .borrow()
 .next
 .as_ref()
 .unwrap()
 .borrow_mut()
 .prev = node.clone();
 self.head.as_ref().unwrap().borrow_mut().next = node.clone();

 self.len += 1;
}

fn push_back(&mut self, node: Option<Rc<RefCell<Node<E>>>>) {
 if node.is_none() {
 return;
 }

 node.as_ref().unwrap().borrow_mut().prev = self.tail.as_ref().unwrap().borrow().prev.clone();
 node.as_ref().unwrap().borrow_mut().next = self.tail.clone();

 self.tail
 .as_ref()
 .unwrap()
 .borrow()
 .prev
 .as_ref()
 .unwrap()
 .borrow_mut()
 .next = node.clone();
 self.tail.as_ref().unwrap().borrow_mut().prev = node.clone();

 self.len += 1;
}

fn pop(&mut self, node: &Option<Rc<RefCell<Node<E>>>>) {
 if node.is_none() {
 return;
 }

 node.as_ref()
 .unwrap()
 .borrow()
 .prev
 .as_ref()
 .unwrap()
 .borrow_mut()
 .next = node.as_ref().unwrap().borrow().next.clone();
 node.as_ref()
 .unwrap()
 .borrow()
 .next
 .as_ref()
 .unwrap()
 .borrow_mut()
 .prev = node.as_ref().unwrap().borrow().prev.clone();

 self.len -= 1;
}

fn pop_front(&mut self) -> Option<Rc<RefCell<Node<E>>>> {
 let front = self.head.as_ref().unwrap().borrow().next.clone();

 if front != self.tail {
 self.pop(&front);

 front
 } else {
 None
 }
}

fn pop_back(&mut self) -> Option<Rc<RefCell<Node<E>>>> {
 let back = self.tail.as_ref().unwrap().borrow().prev.clone();

 if back != self.head {
 self.pop(&back);

 back
 } else {
 None
 }
}

fn len(&self) -> usize {
 self.len
}

我们为双向链表实现了这几个方法：push_front、push_back、pop、pop_front、pop_back和len。虽然部分方法在实现链式哈希表时可能不会用到，但为了让这个双向链表更通用一些，笔者并未删除未用到的“冗余”方法。读者自己实现时可以酌情删除部分用不到的方法。

读到这里，或许有读者会疑惑，这几个方法含unwrap极高，操作双向链表时会不会有可能发生 panic？其实在这里直接使用unwrap是不会出现问题的，原因如下：

初始化双向链表时，head和tail也会初始化为一个确切值。根据push_*方法中的逻辑，在修改head.next或tail.prev时，由于head、head.next、tail和tail.prev已经有值，因此unwrap所接收的值一定是Option::Some(T)。
前三个传入节点指针的方法皆以针对传入的指针做空值校验，这也避免了因传入一个None而导致触发 panic 的情况。(其实，我们一般不会推入/弹出一个空节点指针，因此参数可以写成Rc<RefCell<Node<E>>>，这样连空值校验也不需要了。)

就算如此，在正式项目中，我们仍需要避免直接使用unwrap，而应改用其他更优雅的方式来处理此类情况。当然，本文的重点在于讲解实现思路，因此此类问题在这里就暂时忽略了。

实现链式哈希表

有了前面的双向链表，我们就可以着手实现链式哈希表了。

我们同样先实现其数据结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


use std::collections::HashMap;
use std::hash::Hash;

struct LinkedHashMap<K, V> {
 dll: DoubleLinkedList<(K, V)>,
 hm: HashMap<K, Option<Rc<RefCell<Node<(K, V)>>>>>,
 len: usize,
}

impl<K, V> LinkedHashMap<K, V>
where
 K: Hash + Clone + Default + PartialEq + Eq,
 V: Clone + Default + PartialEq + Eq,
{
 fn new() -> Self {
 Self {
 dll: DoubleLinkedList::new(),
 hm: HashMap::new(),
 len: 0,
 }
 }
}

可以看到，链式哈希表包含dll和hm这两个字段。其中，dll表示双向链表对象，hm表示哈希表对象。为了实现时间复杂度为 O(1) 的增删查改操作，我们使用哈希表，为键和相关双向链表节点之间建立映射。这样，我们就能通过一个键来快速对双向链表元素进行操作了。

接下来，为链式哈希表实现这些方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


fn insert_front(&mut self, key: K, value: V) {
 let node = Some(Rc::new(RefCell::new(Node::new((key.clone(), value)))));

 self.dll.push_front(node.clone());
 self.hm.insert(key, node);

 self.len += 1;
}

fn insert_back(&mut self, key: K, value: V) {
 let node = Some(Rc::new(RefCell::new(Node::new((key.clone(), value)))));

 self.dll.push_back(node.clone());
 self.hm.insert(key, node);

 self.len += 1;
}

fn move_to_front(&mut self, key: K) {
 let node = self.hm.get(&key).unwrap();

 self.dll.pop(node);
 self.dll.push_front(node.clone());
}

fn move_to_back(&mut self, key: K) {
 let node = self.hm.get(&key).unwrap();

 self.dll.pop(node);
 self.dll.push_back(node.clone());
}

fn get(&self, key: K) -> Option<V> {
 self.hm
 .get(&key)
 .map(|node| node.as_ref().unwrap().borrow().element.1.clone())
}

fn get_front(&self) -> (K, V) {
 self.dll
 .head
 .as_ref()
 .unwrap()
 .borrow()
 .next
 .as_ref()
 .unwrap()
 .borrow()
 .element
 .clone()
}

fn get_back(&self) -> (K, V) {
 self.dll
 .tail
 .as_ref()
 .unwrap()
 .borrow()
 .prev
 .as_ref()
 .unwrap()
 .borrow()
 .element
 .clone()
}

fn contains_key(&self, key: K) -> bool {
 self.hm.contains_key(&key)
}

fn remove(&mut self, key: K) -> (K, V) {
 let deleted_node = self.hm.get(&key).unwrap().clone();

 self.dll.pop(&deleted_node);
 self.hm.remove(&key);

 self.len -= 1;

 deleted_node.unwrap().borrow().element.clone()
}

fn len(&self) -> usize {
 assert_eq!(self.len, self.dll.len());
 assert_eq!(self.len, self.hm.len());

 self.len
}

使用方法普通哈希表相似，直接用即可。

实现 LRU

根据题目要求，我们需要完善该框架：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


struct LRUCache {

}


/**
 * `&self` means the method takes an immutable reference.
 * If you need a mutable reference, change it to `&mut self` instead.
 */
impl LRUCache {

 fn new(capacity: i32) -> Self {

 }

 fn get(&self, key: i32) -> i32 {

 }

 fn put(&self, key: i32, value: i32) {

 }
}

/**
 * Your LRUCache object will be instantiated and called as such:
 * let obj = LRUCache::new(capacity);
 * let ret_1: i32 = obj.get(key);
 * obj.put(key, value);
 */

有了前面的链式哈希表，我们就可以直接填充它了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


struct LRUCache {
 cache: LinkedHashMap<i32, i32>,
 cap: usize,
}

impl LRUCache {
 fn new(capacity: i32) -> Self {
 Self {
 cache: LinkedHashMap::new(),
 cap: capacity as usize,
 }
 }

 fn get(&mut self, key: i32) -> i32 {
 if !self.cache.contains_key(key) {
 return -1;
 }

 self.cache.move_to_front(key);
 self.cache.get(key).unwrap()
 }

 fn put(&mut self, key: i32, value: i32) {
 if self.cache.contains_key(key) {
 self.cache.remove(key);
 self.cache.insert_front(key, value);

 return;
 }

 self.cache.insert_front(key, value);

 if self.cache.len() > self.cap {
 let back = self.cache.get_back();
 self.cache.remove(back.0);
 }
 }
}

这里我们规定，双向链表首端代表最新数据，尾端代表最旧数据。当然，读者也可以反过来，只需要把get和put函数中有关front和back的方法换成与其效果相反的那个就可以了。

这里说一句题外话：或许读者将本文代码提交到 LeetCode 后会发现，这种实现所消耗的运行时间有些长了。确实，笔者在实现相关数据结构时，并未考虑性能优化问题。以双向链表节点实现为例，如果我们需要提升性能，那么我们就需要把双向链表指针实现改为Option<NonNull<Node<E>>>（这也是 Rust 标准库所采用的实现），这样就不会产生Rc和RefCell的运行时性能开销了。当然，正如前文所述，本文的重点在于讲解实现思路。因此，在确保自己的实现没有 bug 后，读者可以自行尝试优化实现，提升性能。

实现 LFU

实现 LFU 比实现 LRU 略微复杂。但有了前面的链式哈希表，实现 LFU 相对就没有那么麻烦了。

根据题目要求，我们需要完善该框架：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


struct LFUCache {

}


/**
 * `&self` means the method takes an immutable reference.
 * If you need a mutable reference, change it to `&mut self` instead.
 */
impl LFUCache {

 fn new(capacity: i32) -> Self {

 }

 fn get(&self, key: i32) -> i32 {

 }

 fn put(&self, key: i32, value: i32) {

 }
}

/**
 * Your LFUCache object will be instantiated and called as such:
 * let obj = LFUCache::new(capacity);
 * let ret_1: i32 = obj.get(key);
 * obj.put(key, value);
 */

这里，我们选择使用三哈希表的方式来完成此题。首先，我们先设计好基本的数据结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


struct LFUCache {
 key_to_value: HashMap<i32, i32>,
 key_to_freq: HashMap<i32, i32>,
 freq_to_keys: HashMap<i32, LinkedHashMap<i32, ()>>,
 min_freq: i32,
 cap: usize,
}

impl LFUCache {
 fn new(capacity: i32) -> Self {
 Self {
 key_to_value: HashMap::new(),
 key_to_freq: HashMap::new(),
 freq_to_keys: HashMap::new(),
 min_freq: 0,
 cap: capacity as usize,
 }
 }
}

其中，key_to_value管理普通的键值映射，key_to_freq管理键与相关的频率的映射，freq_to_keys管理频率与键的映射。由于一个频率很可能对应多个键，而且在删除频率最低的键时，若存在多个键，则需删除最久未使用的那个。因此，这里需要使用链式哈希集合来管理这些键。又因为链式哈希集合就是无值链式哈希表，因此我们可以直接使用链式哈希表来构建该数据结构。

在开始实现get和put方法前，我们首先需要实现两个辅助方法：increase_freq和remove_min_freq_key：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


fn increase_freq(&mut self, key: i32) {
 // 如果没有这个键，则不进行任何操作
 if !self.key_to_freq.contains_key(&key) {
 return;
 }

 // 根据键取出与其对应的频率
 let freq = *self.key_to_freq.get(&key).unwrap();
 // 为键更新频率
 self.key_to_freq.insert(key, freq + 1);

 // 根据频率取出与其对应的链式哈希集合，并删除与其对应的元素
 self.freq_to_keys.get_mut(&freq).unwrap().remove(key);
 // 如果删除后该集合为空，则删除该频率——集合映射
 if self.freq_to_keys.get(&freq).unwrap().len() == 0 {
 self.freq_to_keys.remove(&freq);

 // 如果删除的映射正好是表示最低频率的映射，那么增大最低频率
 if freq == self.min_freq {
 self.min_freq += 1;
 }
 }

 // 向新频率——集合映射添加元素
 self.freq_to_keys
 .entry(freq + 1)
 .or_insert(LinkedHashMap::new())
 .insert_front(key, ());
}

fn remove_min_freq_key(&mut self) {
 // 取出最低频率所对应的键
 let keys = self.freq_to_keys.get_mut(&self.min_freq).unwrap();

 // 删除集合中最久未使用的键
 let node = keys.dll.pop_back();
 let key = node.unwrap().borrow().element.0;
 keys.hm.remove(&key);
 keys.len -= 1;
 // 如果删除后该集合为空，则删除该频率——集合映射
 if keys.len() == 0 {
 self.freq_to_keys.remove(&self.min_freq);
 }

 self.key_to_value.remove(&key);
 self.key_to_freq.remove(&key);
}

接下来便可以实现get和put方法了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


fn get(&mut self, key: i32) -> i32 {
 if !self.key_to_value.contains_key(&key) {
 return -1;
 }

 self.increase_freq(key);
 self.key_to_value[&key]
}

fn put(&mut self, key: i32, value: i32) {
 // 如果容量为0，则不进行任何操作
 if self.cap == 0 {
 return;
 }

 // 如果已有键存在，则更新键值映射，且更新键的频率
 if self.key_to_value.contains_key(&key) {
 *self.key_to_value.get_mut(&key).unwrap() = value;
 self.increase_freq(key);

 return;
 }

 // 如果容量已满，则移除最久未使用的键
 if self.key_to_value.len() >= self.cap {
 self.remove_min_freq_key();
 }

 // 在三个哈希表中插入新项
 self.key_to_value.insert(key, value);
 self.key_to_freq.insert(key, 1);
 self.freq_to_keys
 .entry(1)
 .or_insert(LinkedHashMap::new())
 .insert_front(key, ());

 // 由于插入的新项默认频率是1，因此整个缓存中的最低频率便（重新）设置为1
 self.min_freq = 1;
}

至此，LFU 实现完毕。

总结

不难看出，虽然总体上 LRU 和 LFU 的实现比较困难，但只要把大问题分解成几个小问题并逐步解决，那么难度便会骤然下降了。读者可以尝试自己多实现几次，也可以尝试用其他语言再手动实现一次（无论语言是否有提供内置链式哈希表）。

那么，这篇文章就到这里了！希望读者读完本文后可以加深对双向链表、哈希表、LRU 和 LFU 的理解！

要想利用语言内置的双向链表和哈希表手动实现链式哈希表，一个最重要的条件是，我们要能很方便地获取并存储指向双向链表节点的指针，以保证增删查改的时间复杂度均为 O(1)。 ↩︎
虽然 .NET 已内置OrderedDictionary，但由于其底层数据结构为数组和哈希表，因此，其Remove方法时间复杂度为 O(N)，不符合链式哈希表的第二个特点。 ↩︎
crates.io 上有一个社区实现的IndexMap，它可以保证插入元素的顺序。但由于其底层数据结构也为数组和哈希表（和 .NET 的OrderedDictionary一样），因此，其shift_remove方法时间复杂度为 O(N)，而swap_remove方法会破坏元素插入顺序，均不符合链式哈希表的第二个特点。 ↩︎
虽然 Rust 也可以直接使用裸指针，即*const Type和*mut Type，但 Rust 不鼓励使用它们。除非需要与外部函数打交道，或需要极致性能优化，否则使用Option<Rc<RefCell<Node<E>>>>足矣。在保证性能与裸指针不会相差较大的同时，还能最大限度地保障内存安全。 ↩︎

Rust 生命周期简单理解

Sat, 05 Jul 2025 19:06:06 +0800

本文假设读者已有一定 Rust 编程经验，至少能理解所有权和借用的概念与规则。

Rust 有三大核心概念，分别是所有权、借用和生命周期。而在这三大核心概念中，由于生命周期是程序员接触最少的概念。因此，在这三大核心概念中，了解生命周期的概念，优先性是第一位的……好了，编不下去了。（悲）

谈一下为什么我会写这样一篇文章：虽然学习生命周期的前提是理解所有权和借用，但你仍然需要单独学习生命周期的概念。另外，Rust 官方的教程 The Book 给出的关于生命周期的解释也存在一些缺陷（这会在下文提及）。因此，我在此分享一下我对生命周期的理解。

（其实，说是分享我的理解，其实是我希望这篇文章能起到抛砖引玉的作用，为读者——也就是你——深入理解生命周期的概念提供一种新思路。）

当然，人非圣贤，孰能无过？限于本人水平，本文一定存在不少谬误。若有发现，请务必批评指出！

生命周期的历史

首先，必须指出，“生命周期”的概念本身并非由 Rust 首次提出。事实上，古老若 C 语言，它也有生命周期的概念。但它的生命周期概念并不明显，且仅局限于变量及其所在作用域的关系，即：变量的生命周期会在其离开其所在作用域后结束。

C 语言之后的部分语言加强了生命周期的显式概念，如 C++，其变量的生命周期由其创建和销毁的时机决定。如类的构造函数和析构函数：

1
2
3
4
5
6
7
8


class ArbitraryClass {
public:
 int a = 0;
 // 这是构造函数
 ArbitraryClass() { int a = 5; };
 // 这是析构函数
 ~ArbitraryClass() {};
};

使用new和delete来分别调用构造函数和析构函数：

1
2


auto obj = new ArbitraryClass();
delete obj;

这样，我们便可以轻松管控变量obj的生命周期了：使用new函数创建ArbitraryClass的对象，随后使用delete函数释放它。

但是，过去的 C++编译器并不会静态检查变量的生命周期，这可能会导致各种常见问题，如内存泄漏或造成迷途指针等，对内存安全造成威胁。

从 C++11 开始，C++引入了智能指针。它能自动决定何时销毁对象，一定程度上解决了上述问题：

1
2


unique_ptr<ArbitraryClass> obj(new ArbitraryClass());
// 作用域结束时，该指针会被自动释放

当然，智能指针也不能避免某些问题，如产生迷途指针：

1
2
3


unique_ptr<ArbitraryClass> obj(new ArbitraryClass());
// 由于move转移了指针的所有权，因此，原来的obj就变成了迷途指针
auto obj2 = move(obj);

我们可以使用 clangd 或部分 C++编译器（如 gcc）的新版本来分析智能指针释放后的指针调用行为。不幸的是，截至撰写本文时，它们仍然无法识别部分类型的迷途指针调用行为，例如：

1
2
3
4
5
6
7


unique_ptr<ArbitraryClass> obj(new ArbitraryClass());
auto obj2 = move(obj);
// 下面被注释掉的代码能被clangd或gcc正确分析
// auto a = obj;

// 该代码不能被clangd或gcc正确分析
std::cout << obj->a << std::endl;

上述代码可以正常编译通过，且在运行时会发生段错误。因此，C++的生命周期机制也并非十分完善。

或许我们还有其它静态检查工具来规避上述错误，但很遗憾，这些工具是完全可选的！这就意味着 C++程序员需要额外花费精力去了解、配置并运行这些工具。而且，上文提到，静态检查工具也不能检测出所有非法操作行为，这还需要程序员再设置一套完备的代码审查流程，而这对于个人开发者而言几乎不可能做到。

Rust 则是在 C++的基础上更上一层楼。它利用所有权和借用来管理每个值（这里不叫“变量”是因为 Rust 的“变量”默认不可变）的生命周期，以此来保证内存安全。

当然，在开始介绍 Rust 生命周期之前，我们需要简单复习一下所有权和借用的概念。

所有权&借用

首先简要说一下所有权。

Rust 所有权规则无外乎这三点（严谨起见，此处给出英文原文）：

Each value in Rust has an owner.
There can only be one owner at a time.
When the owner goes out of scope, the value will be dropped.

看起来很简单对不对？但它确实是 Rust 不借助 GC 却能保证内存安全的灵魂！所有代码必须遵循这套规则，否则会遭到编译器无情地打回——甚至 unsafe Rust 亦是如此！

拥有复制语义的类型（如i32）无需担心此问题，因为 Rust 会在需要时自动复制一个值，如：

1
2
3


let orig = 5;
let orig2 = orig;
println!("{orig}");

按照所有权规则，此时的orig理应不再持有5，编译报错才对，但上述代码却可以正常编译通过！这正是因为i32类型实现了Copy trait。程序运行时，Rust 会自动复制一个5并赋值给orig2，且不会带来任何性能开销。如此，orig和orig2均持有对 5 的所有权了，代码就能编译通过了。

注意：orig和orig2所持有的5的含义并非相同，因为这两个 5 存储在不同的栈帧。由于i32类型的值存储在栈上，因此，复制一个i32的值，只需要再开辟一个新栈帧即可。这个过程很快，因此这个复制操作不会带来任何性能开销。

接下来再简要说一下借用。

借用，就是向某个值的 owner 借一个值，用完再还给 owner。这和平常人与人之间借东西一样。

当然，开始之前，让我给出一个不等式（不等式做题就是快:D）：

拥有所有权 ≠ 一直持有这个值

其实这也符合人与人之间借东西的情景。譬如，你有一把扳手，别人来借，你手上就没有扳手了。倘使这时又有人来借扳手，你只能告诉他你的扳手被借走了，没法再借他一个（你总不能无中生有一把或故意不借给他吧？）。等到借走你扳手的人把它还回来，你便再次持有了它。在此期间，扳手的 owner 一直是你，但你并非每时每刻都持有它。

Rust 中的借用分为不可变借用及可变借用两种。前者一般也被称为“引用”，后者则是用于值的修改：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


let a = 10;
let mut b = 10;
// 此为不可变借用
let ref_a = &a;
// 此为可变借用
let ref_b = &mut b;
let c = 20;
// 可以对不可变值或可变值进行不可变借用，但不可以对不可变值进行可变借用！
// 如以下被注释掉的代码，去掉注释，程序就不能正常编译运行
// let invalid_mutable_borrow = &mut c;

// Rust还支持这种方式的借用声明
let d = 30;
let ref ref_d = d;

*ref_b *= 3;
assert_eq!(b, 30)

与上述所有权规则类似，借用也有其规则：

At any given time, you can have either one mutable reference or any number of immutable references.
References must always be valid.

简单复习了一下所有权和借用，接下来就要进入正题了。

Rust 生命周期

导入

事实上，我们一般只会接触到所有权和借用这两大概念，对于生命周期了解甚少，因为 Rust 已经帮我们省略了许多显式生命周期标注工作：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


fn main() {
 let s = String::from("text");
 let s2 = receive_and_return_a_string(&s);
 println!("{s}");
 println!("{s2}")
}

fn receive_and_return_a_string(str: &str) -> &str {
 str
}

对于函数receive_and_return_a_string，它的完整形式应是这样：

1
2
3


fn receive_and_return_a_string<'a>(str: &'a str) -> &'a str {
 str
}

由于该函数只有一个形参，因此，借用检查器可以轻松推断出，函数返回值的生命周期只与它有关。发生调用行为时，Rust 将字符串s的借用传入函数，随后又原封不动地将其传出函数并赋值给s2，同时"text"没有走到作用域末尾，值仍然有效。于是编译通过，没有任何问题。

然而对于部分带借用的多形参函数而言，借用检查器就有些力不从心了（汗流浃背了吧借用检查器？:D）：

1
2
3
4
5
6
7


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

代码逻辑简单明了，看似没有任何问题，但编译时就出了问题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


error[E0106]: missing lifetime specifier
 --> src/main.rs:11:33
 |
11 | fn longest(x: &str, y: &str) -> &str {
 | ---- ---- ^ expected named lifetime parameter
 |
 = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `x` or `y`
help: consider introducing a named lifetime parameter
 |
11 | fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
 | ++++ ++ ++ ++

For more information about this error, try `rustc --explain E0106`.

包括 The Book 在内的大部分 Rust 学习书籍都在告诉初学者，添加显式生命周期注解的原因是编译器无法判断要返回x和y中的哪一个，却并为对此展开详细说明。

这正是本文欲达成的核心目的：从理论角度详细解释为什么需要添加显式生命周期注解！这样做还有一个目的就是，编译器不可能在所有情况都能给出有帮助的错误提示，这就需要我们拥有丰富的生命周期知识来修复此类错误！

接下来，我们一同探讨一下需要显式标注生命周期声明的原因。

分析

开始之前，我们需要知道以下几点：

显式生命周期注解是一种特殊的泛型。
生命周期注解的目的在于帮助借用检查器判断不同值之间的生命周期关系，而不是改变某个值的生命周期。
函数在调用时，程序会为其开辟新的作用域空间。这就意味着在一般情况下，函数形参的生命周期与函数本身一致，不受实参影响。

让我们结合具体代码来分析：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


fn main() {
 let x = String::from("abc");
 let a;
 {
 let y = String::from("abcd");
 a = longest(&x, &y);
 }
 println!("{a}")
}

fn longest(first: &str, second: &str) -> &str {
 if first.len() > second.len() {
 first
 } else {
 second
 }
}

容易看出，x 和 y 的生命周期是已知的，且'x大于'y：

1
2
3
4
5
6
7
8
9


fn main() {
 let x = String::from("abc"); // ---------------|
 let a; // |
 { // |
 let y = String::from("abcd"); // ----| |
 a = longest(&x, &y); // 'y 'x
 } // ------------------------------------| |
 println!("{a}") // |
} // ----------------------------------------------|

a的生命周期看起来和x一样，但别忘了，它是个借用（根据函数返回值）。由于借用方生命周期必须小于等于出借方生命周期，因此，它的合法生命周期无法提前得知，必须依赖函数对其的赋值才能确定。

再看longest函数定义：

1
2
3
4
5
6
7


fn longest(first: &str, second: &str) -> &str {
 if first.len() > second.len() {
 first
 } else {
 second
 }
}

可以看出，形参只有first和second这两个对字符串字面量的借用，返回值也是如此。我们知道，调用函数时，程序会在栈内存开辟新的栈帧，将调用的函数压入栈。由于没有显式生命周期注解，因此first和second的生命周期与函数本身的生命周期一致，这就意味着二者会随着函数本身的析构而析构。

换句话就是，函数实参自带的生命周期信息未能和函数形参的生命周期关联起来。

还记得前面提到的“显式生命周期注解是一种特殊的泛型”这句话吗？在这里就体现出来了。由于向函数传参时也会发生模式匹配，因此，匹配实参时，实参自己的生命周期信息会被函数忽略，只匹配借用本身：

1
2
3
4


// 由于没有添加显式生命周期注解，因此，'x和'y被函数忽略
longest( 'x x, 'y y )
 | |
longest(first: &str, second: &str)

这样，函数外部出借方的销毁与否，函数就无从可知了。因此在返回借用时，a 很有可能拿到一个无效借用，这就违反了 Rust 所有权机制，编译出错。

综上，我们便知晓了longest必须添加显式生命周期注解的根本原因：借用检查器无法确定在把借用赋值给a时x和y的生命周期是否仍然有效！详细地说，作为特殊的泛型参数，由于我们没有在函数签名里把这个泛型参数标注出来，因此函数便无法获得x和y的生命周期信息，进而在向函数传参时，借用检查器便无从得知二者的生命周期关系及其有效期了。

大白话就是，借用检查器是个极度保守派，当longest没有生命周期注解时，它会为longest形参脑补一个生命周期，但它不知道实参的生命周期的情况，不敢轻举妄动，否则就可能会引发内存安全问题。

试想一下，假如你在函数里头判断哪个字符串更长时，要返回的那个借用所指向的值被销毁了，而你却并不知情。那么，你把这个借用赋值给a时，你是不是就造成了一个悬垂引用？是不是就引发内存安全问题了？

出于谨慎，借用检查器就要求程序员必须显式告诉它形参、实参与返回值的生命周期关系。

明白原因之后，让我们为函数添加显式生命周期注解：

1
2
3
4
5
6
7


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

此时再调用函数，其模式匹配为：

1
2
3
4


// 'x和'y分别与其对应的形参中的'a对应，函数内部不再为x和y分配新的生命周期
longest( 'x x, 'y y )
 | | | |
longest<'a>(first: &'a str, second: &'a str)

这样，longest函数便同时得到了x和y的借用及其生命周期信息，借用检查器也就能正确分析它们之间的生命周期关系了。同时，由于返回值也声明了'a这个泛型参数，因此，它的生命周期也便能和x和y中的其中一个关联起来了。这样，借用检查器便能正确得出a的合法生命周期了。

有了以上分析，我们将示例代码修改成这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


fn main() {
 let x = String::from("abc");
 let a;
 {
 let y = String::from("abcd");
 a = longest(&x, &y);
 }
 println!("{a}")
}

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

y的长度比x长，因此a会获得对y的借用。但由于y的存活时间比a短，违反了 Rust 借用规则，因此，编译出错。

解决方法如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


fn main() {
 let x = String::from("abc");
 {
 let y = String::from("abcd");
 let a = longest(&x, &y);
 println!("{a}");
 }
}

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

这样，a的存活时间就不大于y了，符合 Rust 借用规则，编译通过，并打印出字符串abcd。

总结

我相信不少初学者在阅读函数生命周期的相关教程时一定会一头雾水。这是因为，在解释函数生命周期的概念时，这类教程既没有着重提及显式生命周期注解的本质，也没有强调函数形参本身也是一种模式匹配。

至于结构体生命周期等，这些就比较简单了，读者可以自行了解。

总而言之，生命周期虽然不是 Rust 独有概念，但它同样也是保证内存安全的一项重要措施。至于显式生命周期注解，它的作用是帮助借用检查器判断不同值之间的生命周期关系。牢记这一点就可以了。

不说了，老婆在喊我回家吃阮饭呢~润了。