智能指针与无锁并发的物理交织 on Dorkytiger 的小屋

`std::unique_ptr` —— 零开销的独占所有权

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

一、物理大小：和裸指针一样大

unique_ptr<int> up(new int(42));

栈上 (up 对象本身，8 字节):
+────────────────────+
| ptr (8字节，64位)   │  ← 就是指向堆上 int 的指针
+────────────────────+

堆上:
+────────────────────+
| 42                  │
+────────────────────+

关键：默认情况下（deleter 是无状态的函数对象/函数指针），unique_ptr 就是一个指针的大小，没有任何额外成员。它的析构函数在编译期被展开为 delete ptr，和裸指针手动 delete 完全一样。

// 汇编层面完全等价：
delete raw_ptr;          // mov rdi, [raw_ptr]; call operator delete
up.reset();              // 同上，mov rdi, [up.ptr]; call operator delete

这就是"零运行时开销"的含义：unique_ptr 在 Release 编译下和裸指针一样快。

二、为什么只能 `std::move` 不能拷贝？

unique_ptr<int> a(new int(42));
unique_ptr<int> b = a;          // ❌ 编译错误：拷贝构造被 delete
unique_ptr<int> c = std::move(a); // ✅ 移动：a 的指针置空，c 接管所有权

物理上的原因：

`std::shared_ptr` —— 引用计数的代价

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

一、16 字节的物理组成

shared_ptr<int> sp(new int(42));

栈上 (sp 对象本身，16 字节):
+──────────────────────+──────────────────────+
| ptr (8字节)          | control_block_ptr     |
| 指向堆上的 int       | 指向控制块            |
+──────────────────────+──────────────────────+

堆上:
+──────────────────────+  ← ptr 指向这里
| int: 42              |
+──────────────────────+

+──────────────────────+  ← control_block_ptr 指向这里（控制块）
| ref_count (原子 int)  |  引用计数
| weak_count (原子 int) |  弱引用计数
| deleter (函数指针)     |  删除器
| allocator (函数指针)   |  分配器
+──────────────────────+

两个堆分配：new int(42) 一次 + 控制块分配一次。这是两 new，两 delete。

二、`std::make_shared` 的合并优化

auto sp = std::make_shared<int>(42);

堆上 (一次 malloc):
+──────────────────────────────────────────────+
| int: 42    | ref_count | weak_count | ...    |
+──────────────────────────────────────────────+
              ↑
栈上 sp: [ptr→这里 | control_block_ptr→这里]
        ptr 指向的地址 = control_block_ptr 指向的地址（在同一个内存块内）

缓存优势：对象和控制块在同一个缓存行内。当 sp 被拷贝时，引用计数 ++ 的操作大概率在 L1 缓存中完成，不需要去主存加载控制块。

`std::weak_ptr` —— 循环引用的解药

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

一、循环引用崩溃现场

struct Node {
    shared_ptr<Node> next;
};

auto a = make_shared<Node>();
auto b = make_shared<Node>();
a->next = b;
b->next = a;  // 💥 循环引用！

a.ptr → [Node A | next→b的control_block]    ref_count_A = 2 (a + b->next)
b.ptr → [Node B | next→a的control_block]    ref_count_B = 2 (b + a->next)

a.reset() → ref_count_A = 1 (还被 b->next 持有) → 不释放
b.reset() → ref_count_B = 1 (还被 a->next 持有) → 不释放
→ 两个节点永远不释放！

二、用 `weak_ptr` 破解

struct Node {
    weak_ptr<Node> next; // 不增加引用计数！
};

a->next = b;  // weak_ptr = b → weak_count++，ref_count 不变
b->next = a;  // 同上

a.reset() → ref_count_A = 0 → 释放 A → b->next 变成空悬
b.reset() → ref_count_B = 0 → 释放 B
✅ 完美释放！

三、`weak_ptr.lock()` 的底层安全检查

shared_ptr<Node> sp = weak_node.lock(); // 安全提升
if (sp) {
    // 此时对象一定活着，sp 持有引用计数
}

底层做了什么：

智能指针与无锁并发的物理交织 on Dorkytiger 的小屋

`std::unique_ptr` —— 零开销的独占所有权

一、物理大小：和裸指针一样大

二、为什么只能 std::move 不能拷贝？

`std::shared_ptr` —— 引用计数的代价

一、16 字节的物理组成

二、std::make_shared 的合并优化

`std::weak_ptr` —— 循环引用的解药

一、循环引用崩溃现场

二、用 weak_ptr 破解

三、weak_ptr.lock() 的底层安全检查

二、为什么只能 `std::move` 不能拷贝？

二、`std::make_shared` 的合并优化

二、用 `weak_ptr` 破解

三、`weak_ptr.lock()` 的底层安全检查