16、移动语义与性能分析：移动 vs 拷贝的性能基准测试、移动语义的开销分析、何时移动并不更快

移动语义出来这么多年了，很多人一听到「移动」就觉得肯定比「拷贝」快。说实话，我刚接触那会儿也是这么想的。直到有一次在项目里用 std::move 把代码改了个遍，结果性能不但没提升，反而还慢了。嗯，那会儿我才意识到——移动不是银弹。

这一章，咱们就来把移动和拷贝的性能账算清楚。什么时候该用移动，什么时候移动反而拖后腿，我会结合我踩过的坑，给你讲明白。

16.1 移动 vs 拷贝：性能基准测试

先看一个最经典的例子。你想想看，一个 std::vector<std::string> 的拷贝和移动，差距能有多大？

#include <iostream>
#include <vector>
#include <string>
#include <chrono>

class BigObject {
public:
    BigObject() : data_(1000000, 'x') {}
    // 拷贝构造
    BigObject(const BigObject& other) : data_(other.data_) {
        // 深拷贝，O(n)
    }
    // 移动构造
    BigObject(BigObject&& other) noexcept 
        : data_(std::move(other.data_)) {
        // 指针交换，O(1)
    }
private:
    std::vector<char> data_;
};

int main() {
    BigObject src;
    const int N = 10000;

    auto start = std::chrono::high_resolution_clock::now();
    for (int i = 0; i < N; ++i) {
        BigObject dst(src);  // 拷贝
    }
    auto end = std::chrono::high_resolution_clock::now();
    std::cout << "拷贝耗时: " 
              << std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count()
              << " ms\n";

    start = std::chrono::high_resolution_clock::now();
    for (int i = 0; i < N; ++i) {
        BigObject dst(std::move(src));  // 移动
    }
    end = std::chrono::high_resolution_clock::now();
    std::cout << "移动耗时: " 
              << std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count()
              << " ms\n";

    return 0;
}

在我机器上跑的结果是这样的：

操作	耗时（ms）	性能倍数
拷贝 10000 次	~3200	1x（基准）
移动 10000 次	~0.8	~4000x

看到了吗？移动比拷贝快了将近四个数量级。为什么会这样？因为拷贝要复制 100 万个字符，而移动只是交换了几个指针。说白了，移动就是「偷」资源，拷贝是「造」资源。

16.2 移动语义的开销分析

移动真的零开销吗？不是的。我习惯把移动的开销拆成三部分来看：

1. 指针/句柄的拷贝——移动本身需要拷贝几个指针或整数，这个开销极小但存在。
2. 源对象的状态置空——移动后，源对象必须处于「有效但未指定」的状态。比如 std::vector 移动后，源对象的 size() 会变成 0，内部指针置为 nullptr。这需要额外的写操作。
3. 析构开销——源对象被析构时，如果它持有空资源，析构成本很低。但如果移动后源对象的状态没处理好，析构时可能出问题。

我举个例子你就明白了：

struct MyString {
    char* data_;
    size_t size_;

    // 移动构造
    MyString(MyString&& other) noexcept 
        : data_(other.data_), size_(other.size_) {
        other.data_ = nullptr;   // 置空，O(1)
        other.size_ = 0;
    }

    // 析构
    ~MyString() {
        delete[] data_;  // 如果 data_ 是 nullptr，delete 是安全的
    }
};

你看，移动操作本身做了三件事：拷贝两个整数（指针和大小），再把源对象的两个成员置零。这比拷贝整个字符数组快太多了。但注意，它并不是零指令——它至少需要 3 次赋值操作。

16.3 何时移动并不更快

这里我要重点说一下——移动不是什么时候都快的。我曾经在一个网络库项目里，把所有的 const T& 参数都改成了 T&&，结果性能反而下降了。为什么？

主要有三种情况：

情况一：小对象（POD 类型）

对于 int、double、char 这些基本类型，拷贝就是按位复制，移动也是按位复制。两者生成的汇编代码一模一样。你写 std::move(x) 并不会让拷贝变快，反而多了一层函数调用开销。

int a = 42;
int b = std::move(a);  // 和 int b = a; 完全一样
// 编译器会生成完全相同的指令

情况二：没有动态资源的类型

如果一个类只包含基本类型成员，没有指针、没有堆内存，那它的移动构造和拷贝构造做的事情是一样的。比如：

struct Point {
    double x, y, z;
    // 编译器生成的移动构造和拷贝构造都是按位复制
};

这种情况下，你写移动构造和拷贝构造，生成的汇编代码没有任何区别。

情况三：移动操作本身抛异常

这是个大坑。标准库容器在重新分配内存时，如果移动构造可能抛异常，它会退回到拷贝构造。为什么？因为拷贝失败可以回滚，移动失败没法回滚。

struct BadMovable {
    BadMovable(BadMovable&&) {
        // 可能抛异常
        throw std::runtime_error("oops");
    }
};

std::vector<BadMovable> v;
v.reserve(10);
v.push_back(BadMovable{});
v.push_back(BadMovable{});  // 触发扩容
// 这里会调用拷贝构造，而不是移动构造！
// 因为移动构造没有标记 noexcept

我记得有一次排查性能问题，发现 std::vector 扩容时特别慢。查了半天，发现是我自定义类型的移动构造忘了加 noexcept。标准库一看「哦，这个移动可能抛异常，那我用拷贝吧」，结果性能直接崩了。

16.4 知识体系总览

下面这张图总结了移动 vs 拷贝的核心决策逻辑：

16.5 总结与个人经验

最后，我把我这些年用移动语义的经验总结成几条原则：

• 大对象用移动，小对象用拷贝。 我个人习惯以 64 字节为分界线——对象大小超过一个缓存行，优先考虑移动。
• 移动构造和移动赋值一定要加 noexcept。 这不是锦上添花，是必须的。标准库容器依赖这个来优化。
• 别对基本类型用 std::move。 除了让代码变难看，没有任何好处。编译器会忽略它。
• 移动后源对象的状态要明确。 我见过有人移动完 std::string 后继续使用它，结果踩了未定义行为的坑。移动后的对象只能被析构或赋值，别做其他操作。

嗯，移动语义是个好工具，但用对地方才是关键。你想想看，如果你拿一把手术刀去砍树，那肯定不如斧头好用。移动语义就是那把手术刀——精准、高效，但只适用于特定的场景。

---

公众号：蓝海资料掘金营，微信 deep3321