三大主流容器的底层内存布局与 CPU 缓存表现 on Dorkytiger 的小屋

`std::vector` 动态数组的内存黑幕

Mon, 01 Jan 0001 00:00:00 +0000

一、物理内存：绝对连续

vector 是 C++ 唯一保证元素在堆内存中绝对连续排列的容器（与 std::array 一样，但 array 在栈上）。

vector<int> v = {10, 20, 30, 40};

堆内存 (Heap):
+──────+──────+──────+──────+──────────────────+
|  10  |  20  |  30  |  40  |  预留空间         |
+──────+──────+──────+──────+──────────────────+
  ^      ^      ^      ^                       ^
  |      |      |      |                       |
v[0]   v[1]   v[2]   v[3]                   v.capacity() - 1

栈上 (Stack) — vector 对象本身 (24 字节，64位):
+────────────────────────────────────────────────────+
| _M_start (ptr)  | _M_finish (ptr) | _M_end_of_storage (ptr) |
| 指向堆首         | 指向堆尾(size)   | 指向容量尾(capacity)    |
+────────────────────────────────────────────────────+

关键结论：

`std::list` 双向链表与 `std::deque` 双端队列

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::list` 的内存灾难

list 的每个节点单独 new 分配，分布在堆的各个角落：

list<int> l = {1, 2, 3, 4};

内存布局 (每个节点独立分配):
堆地址 0x1000: [1 | next→0x2000 | prev←null]
堆地址 0x2000: [2 | next→0x3000 | prev←0x1000]
堆地址 0x3000: [3 | next→0x4000 | prev←0x2000]
堆地址 0x4000: [4 | next←null  | prev←0x3000]

栈上:
list 对象: [_M_node 指向 0x1000 或哨兵节点]

遍历时的缓存行为：

CPU 遍历 list:
  读 0x1000 → Cache Miss (第一次加载缓存行，顺带加载了附近 64 字节的垃圾数据)
  读 0x2000 → Cache Miss (因为 0x2000 和 0x1000 不在同一缓存行)
  读 0x3000 → Cache Miss
  读 0x4000 → Cache Miss
  缓存命中率: ~0% ❌

CPU 遍历 vector:
  读 v[0] → Cache Miss (第一次，加载了 v[0]~v[15] 到缓存行)
  读 v[1] → Cache Hit ✅ (已经在缓存里了)
  读 v[2] → Cache Hit ✅
  ...
  缓存命中率: ~99% ✅

性能差距实测（1 亿次遍历，Release 编译）：

`std::unordered_map` 哈希表与 `std::map` 红黑树

Mon, 01 Jan 0001 00:00:00 +0000

一、`std::map` 红黑树的物理布局

std::map<int, string> m;
m[5] = "five";
m[3] = "three";
m[7] = "seven";

内存中的红黑树结构:
堆地址 0x1000: 节点 3 [left=null|right=0x2000|parent=0x3000|color=RED  |"three"]
堆地址 0x2000: 节点 7 [left=null|right=null |parent=0x3000|color=BLACK|"seven"]
堆地址 0x3000: 节点 5 [left=0x1000|right=0x2000|parent=null|color=BLACK|"five" ]
        ↑
        | (根节点，平衡二叉树)

遍历时的缓存表现：每次通过指针跳到下一节点，和 list 一样——缓存命中率极低。

面试高频题：“为什么 map 的插入是 $O(\log N)$ 但实际可能比 unordered_map 的 $O(1)$ 更快？”

当 N 很小（< 1000）时，红黑树的 $\log N$ 大约 10 次比较，而哈希表需要计算哈希值（几十条指令）+ 取模 + 可能的冲突解决。
哈希表在元素少时，负载因子低，桶空间浪费大，缓存命中率比红黑树还差。

二、`std::unordered_map` 开链哈希表

unordered_map<int, string> um;
um.max_load_factor(1.0);

桶数组 (Bucket Array, 连续内存):
+───────+───────+───────+───────+───────+
| 桶 0  | 桶 1  | 桶 2  | 桶 3  | ...  |
+───┬───+───┬───+───┬───+───┬───+───┬───+
    │       │       │       │
    ▼       ▼       ▼       ▼
   节点     节点     nullptr 节点
   [5]     [13]             [7]
    │       │                │
    ▼       ▼                ▼
  nullptr  nullptr          nullptr
  每个桶指向一个单向/双向链表的头节点

Rehash 的代价：

三大主流容器的底层内存布局与 CPU 缓存表现 on Dorkytiger 的小屋

`std::vector` 动态数组的内存黑幕

一、物理内存：绝对连续

`std::list` 双向链表与 `std::deque` 双端队列

一、std::list 的内存灾难

`std::unordered_map` 哈希表与 `std::map` 红黑树

一、std::map 红黑树的物理布局

二、std::unordered_map 开链哈希表

一、`std::list` 的内存灾难

一、`std::map` 红黑树的物理布局

二、`std::unordered_map` 开链哈希表