18. 移动语义在智能指针中的应用：unique_ptr 的移动语义，shared_ptr 的移动优化

智能指针这东西，说白了就是 C++ 给咱们的「内存管理拐杖」。刚学的时候觉得它麻烦，用久了才发现——真香。尤其是配合移动语义之后，智能指针才真正变得「智能」起来。

我个人习惯把智能指针分成两类来看：独占所有权的 unique_ptr，和共享所有权的 shared_ptr。它们俩对移动语义的运用方式完全不同，但都离不开移动语义这个核心机制。

unique_ptr：天生的「移动型」选手

unique_ptr 的设计哲学很简单：一个资源只能有一个主人。你不能拷贝它，但可以移动它。为什么？因为拷贝意味着两个指针指向同一块内存，那析构时谁负责释放？double free 的噩梦就来了。

来看个例子：

std::unique_ptr<int> ptr1 = std::make_unique<int>(42);
// std::unique_ptr<int> ptr2 = ptr1;  // 编译错误！拷贝构造被删除

std::unique_ptr<int> ptr2 = std::move(ptr1);  // OK，转移所有权
// 此时 ptr1 为空，ptr2 持有资源

我在项目中遇到过好几次这样的场景：有个函数要返回一个在堆上创建的大对象。以前的做法是返回原始指针，然后调用方自己负责 delete。有了 unique_ptr 配合移动语义，一切都变得优雅了：

std::unique_ptr<BigObject> createBigObject() {
    auto obj = std::make_unique<BigObject>();
    // ... 初始化操作
    return obj;  // 自动使用移动语义，甚至不需要 std::move
}

auto myObj = createBigObject();  // 零拷贝，高效

这里有个细节值得注意：函数返回局部 unique_ptr 时，编译器会自动使用移动语义。这是 C++11 引入的「返回值优化（RVO）」与移动语义的结合。你不需要显式写 std::move，编译器比你聪明。

shared_ptr：引用计数的移动优化

shared_ptr 的情况就复杂一些了。它内部维护一个引用计数，拷贝时会增加计数，析构时会减少计数。这个原子操作是有成本的。

移动语义在这里的作用是：避免引用计数的原子增减操作。

你想想看，如果你有一个 shared_ptr，你想把它传给另一个变量。如果走拷贝路线，引用计数要加 1，然后原来的 shared_ptr 析构时再减 1。这一加一减，虽然结果没变，但原子操作的开销是实打实的。

移动就不一样了：

std::shared_ptr<int> sp1 = std::make_shared<int>(100);
std::shared_ptr<int> sp2 = std::move(sp1);  // 引用计数不变！

// sp1 变为空，sp2 持有资源，引用计数仍然是 1

移动后的 sp1 变成了空指针，sp2 接管了资源。引用计数从头到尾没变过——因为资源的所有权只是从一个指针「搬」到了另一个指针，没有新增所有者。

我曾经在优化一个高频交易系统的代码时，发现大量 shared_ptr 的拷贝操作成了性能瓶颈。把那些「用完就丢」的场景改成移动语义后，性能提升了将近 15%。嗯，原子操作的开销在热路径上真的不能忽视。

两种智能指针的移动对比

特性	unique_ptr	shared_ptr
拷贝语义	删除（不允许拷贝）	允许，引用计数 +1
移动语义	转移所有权，原指针置空	转移所有权，引用计数不变
移动后原对象状态	nullptr	nullptr
移动性能优势	唯一传递方式	避免原子操作开销
典型使用场景	独占资源、工厂函数	共享资源、回调、缓存

避坑指南：移动后的智能指针还能用吗？

移动后的 unique_ptr 和 shared_ptr 都变成了空状态。你可以安全地检查它们是否为空，或者重新赋值。但不要对它们解引用——那是未定义行为。

std::unique_ptr<int> up = std::make_unique<int>(5);
auto up2 = std::move(up);

if (!up) {
    // 这里可以安全地检查
    up = std::make_unique<int>(10);  // 重新赋值也没问题
}

// *up = 20;  // 危险！up 为空，解引用是未定义行为

我曾经在代码审查时看到过这样的 bug：有人移动了一个 shared_ptr 后，忘记检查它是否为空，就直接用了。结果程序偶尔崩溃，查了好久才发现是这里的问题。所以我的建议是：移动后立即将原指针置为明确的状态，或者干脆不再使用它。

移动语义在容器中的妙用

智能指针配合容器使用时，移动语义的优势更加明显。比如你要把一个 unique_ptr 放进 vector：

std::vector<std::unique_ptr<int>> vec;
auto ptr = std::make_unique<int>(42);

// vec.push_back(ptr);  // 编译错误！不能拷贝 unique_ptr
vec.push_back(std::move(ptr));  // OK，移动进去

// 或者直接在容器里构造
vec.push_back(std::make_unique<int>(100));  // 临时对象，自动移动

对于 shared_ptr 的容器，如果你确定某个元素不再需要，用移动语义把它移出来，比拷贝再删除要高效得多：

std::vector<std::shared_ptr<int>> sharedVec;
// ... 填充数据

// 取出某个元素，不再保留在容器中
auto elem = std::move(sharedVec[3]);
// sharedVec[3] 现在为空，但引用计数没变

知识体系总览

下面这张图总结了智能指针中移动语义的核心逻辑：

总结一下

移动语义让智能指针真正发挥了它的威力。unique_ptr 靠移动语义实现了独占所有权的传递，shared_ptr 靠移动语义避免了不必要的引用计数操作。两者虽然设计目标不同，但都离不开移动语义这个基础。

在实际编码中，我的建议是：能用 unique_ptr 就别用 shared_ptr。unique_ptr 的语义更清晰，性能更好。只有当确实需要共享所有权时，才考虑 shared_ptr，并且尽量用移动语义来传递它。

嗯，关于智能指针的移动语义，就聊到这里。记住一点：移动语义不是锦上添花，而是智能指针的「灵魂」。没有移动语义，unique_ptr 根本没法用，shared_ptr 的性能也会大打折扣。