手写unique_ptr，彻底吃透C++独占所有权与移动语义

如果只用一句话概括我做完这个练习的感受：unique_ptr 是所有 C++ 智能指针里最值得手写一遍的类。 平时用标准库时，它看起来只是"析构自动 delete"的指针，但当你自己实现一个简化版，才会真正理解独占所有权、移动语义、noexcept 这些概念到底是怎么拧在一起的。这是我 Week 1 Day 2 的练习任务：不依赖标准库，手写一个最小可用的 UniquePtr，然后再把它放进真实的场景里跑一遍。这篇文章就把当天的设计过程、每一行代码背后的原因、以及实测的现象完整记录下来，适合正在学 C++ 移动语义或智能指针的同学参考。

1. 为什么要手写 unique_ptr：独占所有权的底层逻辑

1.1 独占所有权到底在防什么

在 C++11 之前，new 和 delete 的配对完全是程序员自己的责任。漏写一个 delete 就是内存泄漏，多写一个就是 double free。智能指针的核心思路是把"释放资源"这个动作绑定到析构函数上，利用栈上对象生命周期结束时必定析构的特性，让资源管理变成一件"不需要特意记得"的事情。这个思想就是 RAII。

在众多智能指针里，unique_ptr 最特别的地方在于"独占"两个字。独占所有权意味着：同一时刻，只能有一个 unique_ptr 对象拥有它底层的裸指针资源。当这个对象生命周期结束，资源被自动释放；当所有权发生转移，旧对象立刻失去对资源的控制权。

这里最核心的风险是复制。如果允许复制，两个智能指针就会同时指向同一块堆内存，第一个析构时把它 delete 掉，第二个析构时再 delete 一次。这个问题非常隐蔽，因为崩溃往往不出现在资源被释放的那一刻，而是在之后某个看似毫不相关的地方。所以 unique_ptr 从设计上就禁止复制，而且禁止的方式不是运行时检测，而是直接让编译器拦截——这是 C++ "零成本抽象"在资源管理上的经典体现：能编译期解决的问题，绝不拖到运行时。

1.2 为什么自己写一遍比看源码更有效

标准库里的 std::unique_ptr 完整实现有几百行，因为它要处理自定义删除器、数组特化、类型转换、noexcept 规范、空基类优化等大量工程细节。直接读源码，很容易被这些枝节淹没，反而看不清核心机制。

手写一个简化版，就是刻意绕过这些细节，只保留一个裸指针成员和若干关键操作。这样做的好处是：你会被迫回答一系列"为什么"的问题——为什么拷贝要被删除？为什么移动之后源对象必须置空？为什么移动构造函数要加 noexcept？这些问题在阅读源码时容易被忽略，但亲手实现一遍之后，它们会变成肌肉记忆。理解了独占所有权的实现机制，后面再看标准库的完整实现或工程中的各种用法，都会顺畅很多。

2. 第一版最小骨架：构造、析构与禁用拷贝

2.1 成员变量、构造函数与析构函数

第一版只需要一个模板参数和一个裸指针成员，代码如下：

cpp复制template <typename T>
class UniquePtr {
private:
    T* ptr_;

public:
    explicit UniquePtr(T* p = nullptr) : ptr_(p) {}

    ~UniquePtr() {
        delete ptr_;
    }
};

这里有两个值得停下来想清楚的地方。

第一，构造函数为什么加 explicit？因为默认构造函数给了默认参数 nullptr，不做修饰的话，编译器允许从裸指针隐式转换到 UniquePtr。比如 UniquePtr<int> p = new int(42); 这种写法会通过编译，但语义上有点危险：裸指针和智能指针同时存在，外部可能还握着那个原始指针，一旦双方都认为自己对资源拥有控制权，后面必然出问题。加上 explicit，就强制必须以 UniquePtr<int> p(new int(42)); 的形式创建对象，让所有权的归属从一开始就非常清晰。

第二，析构函数为什么可以直接 delete ptr_？因为 this 指针本身是线程安全的，而资源释放只发生一次。当 ptr_ 是 nullptr 时，delete nullptr 是安全操作，不会产生任何效果。这种"空指针安全"是后面很多操作的根基，比如移动后的源对象、默认构造的对象，都可以放心析构。

2.2 用 = delete 直接堵死拷贝

如果不对拷贝做任何处理，编译器会为这个类自动生成默认的拷贝构造函数和拷贝赋值运算符。默认拷贝行为就是把 ptr_ 的值复制一份。结果就是两个 UniquePtr 对象指向同一块内存，析构时 double free。

防止办法很简单直接：

cpp复制    UniquePtr(const UniquePtr&) = delete;
    UniquePtr& operator=(const UniquePtr&) = delete;

= delete 是 C++11 提供的关键能力，它明确告诉编译器：这个操作不存在，谁调用谁编译报错。注意，这里的拦截发生在编译期，不产生任何运行时开销。可以把这个设计理解成一个"所有权的红绿灯"——红灯亮着，任何想复制资源的意图都会在编译阶段被拦下来，而不是等到程序跑起来之后再吞吞吐吐地报错。

对于 unique_ptr 来说，禁止拷贝不是一时取舍，而是独占所有权的必然结果。如果允许复制，就违背了"独占"的定义，整个资源管理模型都会崩掉。

3. 所有权转移的实现细节：移动构造与移动赋值

3.1 std::move 到底做了什么

既然不能拷贝，那所有权怎么转移？答案是移动语义。移动的含义是：把资源的所有权从源对象转给目标对象，同时源对象放弃对资源的控制，变成空指针。

触发移动的方法是 std::move。很多人第一次接触时容易误解，以为 std::move 本身做了"移动"这个动作。其实不是。std::move 只是把对象转换成一个右值引用，让编译器有资格选择移动构造函数或移动赋值运算符。真正的移动逻辑，还是得看这两个函数里怎么写。

对于 UniquePtr 来说，移动操作需要完成两件事：

1. 把源对象的指针拿过来，作为自己的成员。
2. 把源对象的指针置空。

第二步特别重要。如果只做第一步，源对象析构时仍然会对同一块内存执行 delete，double free 照样发生。所以移动的代码必须保证：所有权的转移是彻底的、干净的。

3.2 移动构造函数：用 release 保持语义清晰

一个朴素但正确的移动构造函数可以这样写：

cpp复制    UniquePtr(UniquePtr&& other) noexcept : ptr_(other.ptr_) {
        other.ptr_ = nullptr;
    }

直接复制 other.ptr_，然后手动把它置空。逻辑是对的，但读起来总觉得有点"私自掏对方口袋"的感觉。更优雅的写法是配合后面会实现的 release() 方法：

cpp复制    UniquePtr(UniquePtr&& other) noexcept : ptr_(other.release()) {}

release() 的作用是返回当前持有的裸指针，同时把当前对象置空。调用 other.release()，表达的意思就是"把 other 手里的资源拿出来，并且让 other 彻底放弃管理权"。这样移动构造函数的语义一目了然，也不用直接去访问 other.ptr_。

3.3 移动赋值：先清空自己，再接管别人

移动赋值和移动构造有一个本质区别：移动赋值发生时，当前对象可能已经管理着一块旧资源。必须先把这个旧资源释放掉，再把新资源接管过来；如果忘记释放，旧资源就泄漏了。

最简洁的写法是配合 reset() 方法：

cpp复制    UniquePtr& operator=(UniquePtr&& other) noexcept {
        if (this != &other) {
            reset(other.release());
        }
        return *this;
    }

顺序非常关键。other.release() 先把 other 的资源指针取出来，并让 other 变成空指针。然后 reset(...) 内部做两件事：释放当前对象持有的旧资源，再接管传进来的新指针。整个过程不会出现"两个指针同时指向同一资源"的瞬间。

if (this != &other) 这行是防御性的。虽然 p = std::move(p) 这种写法在正常代码里很少出现，但万一出现，没有这个判断就会出问题：other.release() 会把自己置空，紧接着 reset(nullptr) 又把原本的资源释放掉，结果资源被白白销毁。

3.4 noexcept 不是可选项，而是 vector 扩容时的生死线

移动构造函数和移动赋值运算符我都加了 noexcept。对于 like unique_ptr 这种类型，这不是锦上添花，而是正确使用的前提。

原因在 std::vector 的扩容机制里。当 vector 的容量不足时，会申请一块更大的内存，然后把旧元素逐个搬过去，最后销毁旧内存。如果搬运过程中移动构造函数抛出异常，vector 就处于"一部分元素在旧内存、一部分元素在新内存"的中间状态，异常安全无法保证。因此标准库设计了一个机制：如果元素的移动构造是 noexcept，就放心使用移动；否则，只要元素支持拷贝，就退回拷贝。

问题来了：我们的 UniquePtr 是"可移动但不可拷贝"的类型。如果移动构造函数不是 noexcept，vector 在扩容时既不能安全地移动，又没有拷贝可用，这个类型放进 vector 就非常危险。标准库对这种场景的处理策略是：在无法安全移动且无法拷贝的情况下，仍然尝试移动，但一旦抛出异常，灾难就发生了。

所以，凡是为容器准备的可移动不可拷贝类型，移动构造函数务必标记 noexcept。这不是风格偏好，而是标准库容器对异常安全的基本要求。

4. 把接口补完整：get、release、reset 与 bool 判定

4.1 get：只观察，不转让

get() 是最简单的接口，返回内部指针的副本：

cpp复制    T* get() const noexcept { return ptr_; }

它的用途是"查看"当前管理的裸指针，比如传给某些需要裸指针的 C 接口。但要记住一个原则：get() 返回的裸指针不拥有资源，不能对它执行 delete，也不要长期保存它。因为 UniquePtr 随时可能析构，一旦它析构了，你手里那个裸指针就成了悬空指针。

可以理解为：get() 是把资源借给你看一眼，但资源的所有权始终在 UniquePtr 手里，借出的指针随时可能失效。

4.2 release：把所有权交还给你

cpp复制    T* release() noexcept {
        T* old = ptr_;
        ptr_ = nullptr;
        return old;
    }

release() 是唯一一个把资源"还给你"的接口。调用之后，UniquePtr 不再管理这块内存，调用方拿到了裸指针，并且需要自己负责后续的释放。

一个常见的误用是只调用 release() 却不接收返回值：

cpp复制p.release(); // 内存泄漏！

这就把资源所有权凭空扔掉了，之后没有人再释放它，内存泄漏就发生了。正确用法必须保存返回值，或者把返回值直接交给另一个资源管理器。

release() 的价值在于"所有权转移给外部"的场景。比如你写了一个函数，生成一个对象并返回裸指针交给调用方，调用方可能决定用 unique_ptr 接管，也可能用 shared_ptr 接管，甚至可能直接管理。这个时候用 release 明确表示"我不再负责，接下来看你的了"。

4.3 reset：安全地替换资源

cpp复制    void reset(T* p = nullptr) noexcept {
        T* old = ptr_;
        ptr_ = p;
        delete old;
    }

reset() 做的事是：释放当前持有的资源，然后接管新传入的指针；如果不传参数，默认接管 nullptr，效果就是单纯释放当前资源。

一个关键的细节是：代码里先把旧指针保存下来，把 ptr_ 指向新资源，再 delete old。如果反过来，先 delete ptr_ 再赋新值，万一 delete 过程中出问题，新指针就丢了。先设新值再释放旧的，能让对象的内部状态保持在一个一致的区间。

在移动赋值里使用 reset(other.release())，就是充分利用了 release 和 reset 的语义分工：一个负责"剥离"，一个负责"替换"。

4.4 explicit operator bool：把空指针判断写得更自然

cpp复制    explicit operator bool() const noexcept { return ptr_ != nullptr; }

这个转换运算符的意义在于，可以直接写出 if (p) 或 if (!p) 这样的代码，不需要 if (p.get() != nullptr)。

explicit 的作用是禁止隐式转换。如果不加 explicit，UniquePtr<int> p; int* q = p; 这种荒谬的代码也能通过编译——因为编译器会尝试把 UniquePtr 转成 bool，bool 再转成 int*。加上 explicit 之后，只有显式的布尔上下文（如 if、while、!）才会触发转换，避免了隐式转换带来的意外。这是现代 C++ 里推荐的写法。

到这里，一个真正可用的简化版 UniquePtr 就完成了。完整代码放在测试之前展示，方便对照。

5. 完整实现与测试：在日志里观察对象的生与死

5.1 完整代码一览

下面是我当天最终整理出的精简版实现，同时包含前面几个部分讨论的所有接口：

cpp复制#include <iostream>
#include <utility>

template <typename T>
class UniquePtr {
private:
    T* ptr_;

public:
    explicit UniquePtr(T* p = nullptr) noexcept : ptr_(p) {}

    ~UniquePtr() {
        delete ptr_;
    }

    UniquePtr(const UniquePtr&) = delete;
    UniquePtr& operator=(const UniquePtr&) = delete;

    UniquePtr(UniquePtr&& other) noexcept : ptr_(other.release()) {}

    UniquePtr& operator=(UniquePtr&& other) noexcept {
        if (this != &other) {
            reset(other.release());
        }
        return *this;
    }

    T& operator*() const { return *ptr_; }
    T* operator->() const { return ptr_; }
    T* get() const noexcept { return ptr_; }
    T* release() noexcept {
        T* old = ptr_;
        ptr_ = nullptr;
        return old;
    }
    void reset(T* p = nullptr) noexcept {
        T* old = ptr_;
        ptr_ = p;
        delete old;
    }

    explicit operator bool() const noexcept { return ptr_ != nullptr; }
};

这个版本没有做任何性能妥协，所有关键路径上都没有虚函数、没有锁、没有多余的堆分配。它的大小和裸指针一样，行为上已经非常接近标准库的核心语义了。

5.2 用带日志的 Resource 类观察生命周期

为了直观看到对象何时被创建、何时被销毁，我定义了一个简单的日志类：

cpp复制class Resource {
public:
    explicit Resource(int id) : id_(id) {
        std::cout << "Resource " << id_ << " created\n";
    }
    ~Resource() {
        std::cout << "Resource " << id_ << " destroyed\n";
    }
    int id() const { return id_; }

private:
    int id_;
};

然后写了一段完整的测试代码，覆盖构造、移动、赋值、作用域析构、放入容器等场景：

cpp复制UniquePtr<Resource> createResource(int id) {
    return UniquePtr<Resource>(new Resource(id));
}

int main() {
    UniquePtr<Resource> p1(new Resource(1));
    std::cout << "p1 holds id=" << p1->id() << "\n";

    UniquePtr<Resource> p2(std::move(p1));
    if (!p1) {
        std::cout << "p1 is empty after move\n";
    }

    p2 = createResource(2);
    std::cout << "after p2 = createResource(2), p2 holds id=" << p2->id() << "\n";

    std::vector<UniquePtr<Resource>> vec;
    vec.reserve(1);
    vec.push_back(UniquePtr<Resource>(new Resource(3)));
    vec.push_back(UniquePtr<Resource>(new Resource(4)));
    std::cout << "vector size=" << vec.size() << "\n";

    return 0;
}

5.3 运行结果分析

这段代码在我的环境里输出如下：

code复制Resource 1 created
p1 holds id=1
p1 is empty after move
Resource 2 created
Resource 1 destroyed
after p2 = createResource(2), p2 holds id=2
Resource 3 created
Resource 4 created
vector size=2
Resource 4 destroyed
Resource 3 destroyed
Resource 2 destroyed

每一行都值得对照代码推演一遍。

Resource 1 created 是 p1 构造时打印的。之后 p2(std::move(p1)) 把资源 1 的所有权从 p1 转给 p2，因此输出 p1 is empty after move。注意这里没有打印 Resource 1 destroyed，因为资源对象本身没有被销毁，只是换了一个管理者。

p2 = createResource(2) 的过程很有意思：先打印 Resource 2 created，然后当临时对象移动赋值给 p2 时，p2 先释放旧的资源 1，所以出现 Resource 1 destroyed，紧接着 p2 接管资源 2。整个过程资源 2 没有被销毁，资源 1 也只有一次正确的销毁。这就是 reset(other.release()) 的行为。

vector 部分更能说明移动语义的价值。vec.reserve(1) 预留了一个元素的空间，第一次 push_back 把资源 3 放进去。第二次 push_back 时容器容量不足，需要扩容到 2。此时 vector 要把旧元素从旧内存移动到新内存，由于 UniquePtr 的移动构造函数是 noexcept，这个操作被安全地执行，资源 3 的地址其实没变，只有它的管理器从旧内存移动到了新内存。整个过程没有打印 Resource 3 destroyed，说明资源在迁移过程中没有被误释放。

程序最后，vector 析构先销毁资源 4 和资源 3，然后 p2 析构销毁资源 2。每个资源恰好被销毁一次，没有泄漏也没有 double free。

6. 与标准库的差距：删除器、数组特化与日常选型

6.1 自定义删除器：当 delete 不再是正确选择

简化版 UniquePtr 在析构时调用 delete ptr_，这是针对 new 出来的单对象的标准释放方式。但真实工程里，管理的资源并不全是 new 出来的对象。举个例子，如果要用 RAII 管理一个文件指针：

cpp复制auto closer = [](FILE* f) {
    if (f) std::fclose(f);
};
std::unique_ptr<FILE, decltype(closer)> file(std::fopen("config.ini", "r"), closer);

FILE* 是通过 fopen 得到的，释放方式不是 delete，而是 fclose。标准库的 unique_ptr 专门提供了第二个模板参数来承载这种"自定义删除器"能力。传入的删除器是一个可调用对象，它在析构时被调用，代替默认的 delete。

自定义删除器的设计价值在于：unique_ptr 不假设资源一定来自 new，它只负责"某个资源在生命周期结束时触发某个释放动作"。文件句柄、互斥锁、socket 描述符，甚至是从自定义对象池里分配的内存块，都可以用 unique_ptr 来管理，只要把对应的释放逻辑写进删除器。

标准库在这个基础上还做了空基类优化，如果删除器是无状态的对象或 lambda，unique_ptr 的大小仍然保持和一个裸指针一样，不额外增加存储开销。

在简化版里我没有实现删除器，因为那会引入很多模板细节。但如果你打算在工程里继续扩展这个练习，自定义删除器是优先级最高的一个方向。

6.2 数组特化：管理数组资源需要用对释放方式

另一个容易被忽略的坑是数组。如果你写：

cpp复制std::unique_ptr<int> p(new int[10]);

这在语法上会编译通过，但行为是未定义的。因为 unique_ptr<int> 的析构函数调用的是 delete，而数组应该使用 delete[]。这两者释放内存的方式不同，混用可能导致堆损坏。

标准库通过模板特化来解决这个问题：std::unique_ptr<T[]> 专门用来管理数组，它在内部调用 delete[]，同时数组版本的接口也做了调整，比如不提供 operator* 和 operator->，而是提供 operator[] 来访问元素。

这也是自己实现一个简化版时最容易忽略的地方。如果你发现需要管理动态数组，就应该立刻想到使用数组版本的 unique_ptr，或者直接改用 std::vector 来持有元素，让容器自己处理内存分配和释放。

6.3 日常工程里的正确打开方式

手写这个简化版的另一个收获，是重新审视了 unique_ptr 在日常工程中的位置。

我自己的使用准则是：当函数需要持有某个对象的资源，并且这个对象不应该有多个所有者时，一律优先使用 unique_ptr。它是所有智能指针里语义最明确、开销最低的选择，也比裸指针安全得多。

在传参的时候要特别区分所有权语义。如果函数只是读取对象，不打算保存它，应该传 T*、const T& 或 const T*；如果函数要接管对象所有权，应该显式接收 std::unique_ptr<T> 的右值参数。这样在函数签名里就能把"谁拥有资源"理清楚，而不是依赖注释或惯例。

一个值得养成的习惯是使用 std::make_unique 来创建对象，而不是 unique_ptr<T>(new T(...))。虽然 C++17 之后求值顺序的问题已经修复，但 make_unique 仍然更简洁，而且它避免了在任何地方直接出现裸指针，从编码风格上就更安全。

unique_ptr 还有一个特别实用的特性：它可以被转换成 shared_ptr，因为独占所有权可以升级为共享所有权，而反过来不行。这给代码演进留了后路：先返回 unique_ptr，如果后续调用方确实需要多个所有者，再转成 shared_ptr，不需要改动已有实现。

手写一遍 unique_ptr 之后，再回过头看标准库里的 std::unique_ptr，很多当初觉得多余的模板参数和约束，现在都有了落地的理由。如果你也想深入理解 C++ 的资源管理，我建议按照这个路径亲手实现一次——不是抄一遍标准库，而是只做自己需要的最小版本。实现完再回来用 std::unique_ptr 写业务代码，整个感觉会完全不一样。