3、显存分配与释放：cudaMalloc/cudaFree的正确使用、内存泄漏的常见场景、cudaMallocManaged的陷阱

显存管理，说白了就是GPU编程的“地基”。地基没打好，上面盖多漂亮的楼都得塌。我见过太多同学，核函数写得飞起，一跑就崩，最后发现是显存分配出了问题。今天咱们就把这块掰开揉碎了讲清楚。

3.1 cudaMalloc与cudaFree：基本功要扎实

cudaMalloc和cudaFree是CUDA显存管理的“左右手”。用法很简单，但坑不少。

// 正确用法
float *d_data;
cudaMalloc(&d_data, N * sizeof(float));
// ... 使用显存 ...
cudaFree(d_data);

嗯，这里要注意：cudaMalloc的第一个参数是指针的地址（二级指针），不是指针本身。我刚开始学CUDA时，就犯过这个低级错误——传了d_data而不是&d_data，结果程序静默失败，查了半天。

3.2 内存泄漏的常见场景

内存泄漏，GPU编程的“慢性毒药”。我曾在项目中排查过一个泄漏问题，程序跑12小时后显存爆满，整个集群都被我搞崩了。后来发现是下面这种场景：

// 泄漏场景1：忘记释放
for (int i = 0; i < 1000; i++) {
    float *d_temp;
    cudaMalloc(&d_temp, 1024 * sizeof(float));
    // 使用d_temp...
    // 忘记cudaFree(d_temp)！
}

每次循环分配1KB，1000次就是1MB。看着不多？如果每次分配100MB，跑1000次就是100GB。显存才多大？

还有一种更隐蔽的泄漏：

// 泄漏场景2：异常路径未释放
void process_data(float *h_data) {
    float *d_data;
    cudaMalloc(&d_data, N * sizeof(float));
    
    cudaMemcpy(d_data, h_data, N * sizeof(float), cudaMemcpyHostToDevice);
    
    // 如果这里抛出异常或提前return
    if (some_error_condition) {
        return;  // d_data没释放！
    }
    
    // 正常处理...
    cudaFree(d_data);
}

我个人习惯用RAII思想来管理显存——写一个简单的封装类，在析构函数里自动调用cudaFree。这样不管函数怎么退出，显存都能安全释放。

3.3 cudaMallocManaged的陷阱

cudaMallocManaged（统一内存）听起来很美：自动迁移数据，不用手动拷贝。但陷阱比好处多。

// 看似简单的用法
float *data;
cudaMallocManaged(&data, N * sizeof(float));
// 在CPU上初始化
for (int i = 0; i < N; i++) data[i] = i;
// 在GPU上使用
kernel<<<blocks, threads>>>(data);
cudaDeviceSynchronize();
cudaFree(data);

为什么说这是陷阱？

• 性能陷阱：统一内存会在CPU和GPU之间频繁迁移数据。你想想看，每次核函数访问数据，都可能触发一次页面迁移。我测试过一个项目，用cudaMallocManaged比手动管理慢了10倍。
• 并发陷阱：多个流（stream）同时访问统一内存时，可能触发页面错误风暴。GPU会暂停所有线程等待数据迁移，性能直接崩盘。
• 容量陷阱：统一内存默认使用CPU内存作为后备存储。如果显存不够，它会自动换出数据。但换出换入的开销，有时候比重新计算还大。

我曾经接手过一个项目，前任工程师全程用cudaMallocManaged，代码看着很简洁。一跑性能测试，惨不忍睹。我花了三天把所有统一内存改成手动管理，性能提升了8倍。嗯，这个故事告诉我们：简洁不等于高效。

3.4 显存管理的核心流程图

下面这张图总结了我个人认为的显存管理核心流程：

3.5 总结一下

显存管理其实就三句话：

• 分配要检查——别假设显存永远够用
• 释放要彻底——所有路径都要释放，包括异常路径
• Managed要慎用——方便是方便，性能代价你得扛得住

我个人习惯在代码里加一个显存统计模块，每次分配和释放都记录一下。这样一旦泄漏，能快速定位到是哪个模块的问题。你想想看，排查泄漏最怕什么？最怕不知道泄漏了多少、从哪里泄漏的。有了统计，问题就清晰多了。