4. memcpy的陷阱：浅拷贝与深拷贝，标准库函数在算子中的局限性

内存拷贝，听起来很简单对吧？

很多新手工程师觉得，不就是把一块数据从A搬到B嘛，用memcpy就完事了。嗯，我当年也是这么想的。直到有一次，我调试一个自定义的Tensor类，数据怎么都不对，查了整整两天，最后发现是浅拷贝惹的祸。

今天咱们就来聊聊，memcpy在算子优化里到底有哪些坑。说白了，就是浅拷贝和深拷贝的区别，以及为什么标准库函数有时候并不好用。

4.1 浅拷贝 vs 深拷贝：一个指针引发的血案

先看一个最简单的例子。假设我们有一个张量类，里面有个指针指向实际数据：

class Tensor {
public:
    float* data;
    size_t size;
    
    Tensor(size_t n) : size(n) {
        data = new float[n];
    }
    
    // 默认的拷贝构造函数 - 浅拷贝！
    Tensor(const Tensor& other) : size(other.size), data(other.data) {
        // 只是复制了指针，没有复制数据
    }
    
    ~Tensor() {
        delete[] data;
    }
};

你看，这里有个大问题。两个Tensor对象共享同一块内存。当其中一个被析构时，另一个的data指针就成了野指针。这就是典型的浅拷贝陷阱。

⚠️ 我曾经踩过的坑： 在写一个矩阵乘法算子时，我用memcpy复制了一个临时张量的元数据。结果临时张量一释放，主张量的数据指针就悬空了。程序跑起来时好时坏，特别难复现。后来我才意识到，memcpy只拷贝了指针值，没拷贝指针指向的内容。

那深拷贝怎么做？很简单，重新分配内存，再把数据复制过去：

// 深拷贝版本
Tensor(const Tensor& other) : size(other.size) {
    data = new float[size];
    memcpy(data, other.data, size * sizeof(float));
}

嗯，这里要注意。深拷贝虽然安全，但代价很高。每次拷贝都要分配内存和复制数据。在算子优化中，我们经常要权衡：是冒着风险用浅拷贝，还是牺牲性能用深拷贝？

4.2 标准库函数的局限性

memcpy、memmove、std::copy这些函数，在CPU上确实很快。但放到算子优化的场景里，它们就有不少局限性了。

函数 适用场景 局限性
memcpy 内存不重叠的拷贝 不支持重叠区域；对齐要求高
memmove 内存可能重叠的拷贝 比memcpy略慢；同样有对齐问题
std::copy 泛型拷贝 对POD类型退化为memcpy；非POD类型有额外开销

我个人的习惯是，在算子内部尽量少用这些标准库函数。为什么？有三个原因。

第一，对齐问题。 memcpy在拷贝未对齐的数据时，性能会大幅下降。比如你有一个自定义的half精度类型，内存对齐是2字节，但memcpy默认按4或8字节对齐来优化，反而会出问题。

第二，缺乏语义信息。 标准库函数不知道你在拷贝什么。是张量的连续内存？还是稀疏矩阵的非零元素？它只管搬字节，不管业务逻辑。这就导致很多优化机会白白浪费了。

第三，CUDA环境下的坑。 这个我得多说两句。在GPU编程里，memcpy根本不能用。你得用cudaMemcpy，而且还要指定拷贝方向：

// CPU上的写法 - 在GPU上不行！
// memcpy(gpu_data, cpu_data, size);

// CUDA的正确写法
cudaMemcpy(gpu_data, cpu_data, size, cudaMemcpyHostToDevice);
cudaMemcpy(cpu_data, gpu_data, size, cudaMemcpyDeviceToHost);
cudaMemcpy(gpu_data1, gpu_data2, size, cudaMemcpyDeviceToDevice);
💡 一个小技巧： 在写算子时，我建议封装自己的拷贝函数。比如CopyTensorData，内部根据设备类型（CPU/GPU）和内存布局（连续/非连续）自动选择最优的拷贝方式。这样既安全，又方便后续优化。

4.3 算子中的实际案例：Strided Tensor的拷贝

咱们来看一个实际场景。很多算子处理的是strided tensor，也就是内存不连续的张量。比如一个矩阵的转置，或者一个子矩阵的切片。

这时候，直接用memcpy就完蛋了。因为它只能拷贝连续内存。你想想看，如果数据在内存里是跳着存的，memcpy会把不相关的数据也拷贝过去。

正确的做法是逐行拷贝：

// 拷贝一个strided tensor
void CopyStridedTensor(float* dst, const float* src, 
                       size_t rows, size_t cols, 
                       size_t src_stride, size_t dst_stride) {
    for (size_t i = 0; i < rows; ++i) {
        // 每次拷贝一行连续数据
        memcpy(dst + i * dst_stride, 
               src + i * src_stride, 
               cols * sizeof(float));
    }
}

你看，这里memcpy还是有用武之地的，但需要我们自己控制拷贝的粒度。说白了，就是把非连续的问题，拆解成多个连续的拷贝操作。

📌 我的经验： 在优化这类拷贝时，可以尝试合并小的拷贝操作。比如把多个小行合并成一个大块来拷贝，减少函数调用开销。但要注意边界对齐，别把数据搞乱了。

4.4 知识结构图

下面这张图，总结了本章的核心逻辑。从浅拷贝的陷阱，到标准库函数的局限，再到算子中的实际应对策略，一目了然。

memcpy陷阱与标准库函数局限性 内存拷贝核心问题 浅拷贝：指针共享 深拷贝：内存独立 陷阱：野指针、double free memcpy/memmove/std::copy 局限性：对齐、语义、CUDA 应对：封装、逐行拷贝 核心原则： 理解数据布局，选择合适的拷贝策略

4.5 避坑指南

最后，我总结几条实战经验，希望能帮你少走弯路。

  • 永远不要假设内存是连续的。 尤其是在处理张量切片、转置、广播等操作时。先检查内存布局，再决定拷贝策略。
  • 封装自己的拷贝函数。 把设备类型、内存布局、对齐要求都考虑进去。这样代码更清晰，也方便后续做性能优化。
  • 小心生命周期管理。 如果用了浅拷贝，一定要确保原始对象的生命周期长于拷贝对象。否则，用智能指针或者引用计数来管理。
  • 在CUDA里别用memcpy。 这个我说过了，但还是要强调。用cudaMemcpy，并且明确指定拷贝方向。异步拷贝时还要注意同步问题。

嗯，关于内存拷贝的陷阱，今天就聊到这儿。记住一句话：拷贝不是简单的搬砖，理解数据的本质，才能写出高效的算子。

← 上一章 📖 返回目录 下一章 →