C++内存拷贝：深拷贝与浅拷贝的陷阱与优化

1. 从物理搬运到程序崩溃：C++内存拷贝的本质解析

在C++开发中，内存拷贝就像建筑工地的材料搬运工，看似简单却暗藏玄机。当我们声明一个结构体变量并赋值给另一个变量时，编译器实际上执行的是最原始的二进制搬运：

cpp复制struct SensorData {
    float temperature;
    double humidity;
    uint16_t pressure;
}; // 总大小14字节（考虑对齐后可能是16字节）

SensorData outdoor = {25.3, 65.2, 1013};
SensorData backup = outdoor; // 触发16字节的二进制搬运

这种搬运方式对于基本数据类型堪称完美，就像复印机复制文档一样可靠。但问题在于，现实中的数据结构往往比这复杂得多。我曾经在无人机飞控系统中遇到过这样一个结构体：

cpp复制struct FlightLog {
    uint64_t timestamp;
    char* rawData;  // 指向动态分配的飞行数据
    size_t dataSize;
};

当这样的结构体发生默认拷贝时，灾难的种子就此埋下。编译器只会忠实地复制指针值本身，而不会关心指针指向的内容。这就好比复印了一份保险箱钥匙的设计图，却没有复制保险箱里的珠宝。

2. 浅拷贝陷阱的多维度分析

2.1 单线程环境下的隐患

即使不考虑多线程，浅拷贝也会带来诸多问题。最常见的是双重释放（double free）问题：

cpp复制FlightLog log1;
log1.rawData = new char[1024]; // 分配1KB空间

FlightLog log2 = log1; // 浅拷贝

delete[] log1.rawData; // 第一次释放
delete[] log2.rawData; // 第二次释放同一内存 - 崩溃！

我在早期开发机器人控制系统时就犯过这个错误。当时系统会在运行几小时后随机崩溃，经过两天调试才发现是日志模块的浅拷贝问题。

2.2 多线程环境的连锁反应

当多个线程操作浅拷贝产生的对象时，问题会呈指数级放大。考虑以下场景：

cpp复制struct SharedConfig {
    char* networkConfig;
    std::atomic<bool> isConnected;
};

SharedConfig config;
config.networkConfig = new char[256];
strcpy(config.networkConfig, "192.168.1.100");

// 线程A：
void updateConfig() {
    delete[] config.networkConfig;
    config.networkConfig = new char[256];
    strcpy(config.networkConfig, "10.0.0.1");
}

// 线程B：
void useConfig() {
    printf("Connecting to %s", config.networ