cudamalloc失败主因是显存被占满或驱动异常；pinned内存是异步传输前提；__device__变量不自动分配显存；cudamemcpy同步导致性能差，需用cudamemcpyasync配合stream和pinned内存。
cudaMalloc 分配显存失败的常见原因
cudaMalloc 返回 cudaErrorMemoryAllocation 或卡死，大概率不是代码写错了，而是显存被其他进程占满，或者驱动没加载好。CUDA 上下文在首次调用时隐式初始化，如果此时 GPU 正在跑训练任务、桌面合成器（比如 GNOME 的 Mutter）占着显存，或 Docker 容器没加 --gpus，cudaMalloc 就会失败。
- 检查显存占用：运行
nvidia-smi，看Memory-Usage和Processes列 - 确保 CUDA 上下文干净：在
cudaMalloc前加一句cudaSetDevice(0)，避免多卡环境下默认选错设备 - Windows 用户注意 WDDM 模式限制：桌面 GPU（如 RTX 4090）在 WDDM 下单次
cudaMalloc最大只支持约 2GB，切到 TCC 模式（需 Tesla/Quadro/A100 或数据中心卡）才能绕过
host 内存 pinned 后为什么 memcpy 更快
普通 malloc 分配的内存是 pageable 的，GPU DMA 不能直接访问；调用 cudaMallocHost（或 cudaHostAlloc）分配的 page-locked 内存，才能让 GPU 异步拷贝不经过 CPU 中转。这不是“优化技巧”，而是异步传输的硬性前提。
-
cudaMemcpyAsync必须搭配cudaMallocHost分配的 host 内存，否则退化为同步行为 - pinned 内存会锁住物理页，影响系统整体内存调度，别滥用：只对频繁传输的中等大小 buffer（比如几 MB 到百 MB）使用
- Linux 下可能触发
cudaErrorMemoryAllocation：内核参数vm.max_map_count太低，需调高（例如设为 262144）
__device__ 变量和 cudaMalloc 的生命周期区别
<strong>device</strong> 变量（如 <strong>device</strong> float *d_data）只是声明一个 device 地址，不自动分配空间；它常用于全局符号导出，或配合 cudaGetSymbolAddress 动态绑定。真正分配显存还得靠 cudaMalloc。
-
<strong>device</strong>变量不能直接赋值指针，必须用cudaMemcpyToSymbol把地址传过去 - 如果你写了
<strong>device</strong> float arr[1024]，这是静态分配在 global memory，编译期就占显存，且无法 resize - 动态 size 场景一律用
cudaMalloc+cudaFree，别试图用<strong>device</strong>数组替代
cudaMemcpy 默认同步行为的实际影响
cudaMemcpy 是同步函数，CPU 会卡住直到传输完成。这在调试时“看起来很稳”，但实际性能极差——GPU 计算和 host 传输完全串行。
立即学习“C++免费学习笔记（深入）”；
- 替换方案：用
cudaMemcpyAsync+ stream，但必须确保 host 内存是 pinned 的 - 注意 stream 依赖：如果 kernel 和 memcpy 共用默认 stream（0），
cudaMemcpyAsync仍会等 kernel 结束，得显式创建非默认 stream 并传给两者 - 避免误用
cudaMemcpy在循环里：每帧拷贝 1MB 图像，同步调用会让 GPU 利用率掉到 20% 以下
显存管理真正麻烦的不是分配本身，而是不同 lifetime 的对象混在一起：kernel 参数里的 device 指针、stream 上挂的异步任务、host 端生命周期不确定的 pinned buffer。一个 cudaFree 漏掉，或提前 free 了还在 stream 里排队的内存，错误往往延迟几秒才爆发成 cudaErrorIllegalAddress。
