cudaMallocManaged实现按需迁移而非自动免维护，需调用cudaDeviceSynchronize保证CPU写入对GPU可见，且指针不可直接交由std::vector等RAII容器管理。
统一内存不是“自动免维护”，而是把显式拷贝换成按需迁移——用对了能省事，用错了反而更难调试。
cudaMallocManaged 分配后必须调用 cudaDeviceSynchronize 才能保证 GPU 看到 CPU 写入的数据
很多人以为 cudaMallocManaged 分配完、CPU 写完数据，GPU 内核就能立刻读到最新值。实际不是：写操作发生在 host 端，但 GPU 端的缓存或页面状态可能还没更新。不加同步，内核常读到旧值或未初始化内存。
-
cudaDeviceSynchronize()是最简单可靠的强制同步点，尤其在首次写完后立即调用 - 若在循环中反复 CPU 写 → GPU 算 → CPU 读，每次切换访问方都建议加
cudaDeviceSynchronize()或更细粒度的cudaStreamSynchronize() - 忽略同步时常见错误现象：
kernel 输出全为 0、segmentation fault on device access（因页面尚未迁移到 GPU）
统一内存指针不能直接传给 std::vector 或 std::unique_ptr 管理
cudaMallocManaged 返回的是裸指针，其生命周期由 CUDA 运行时管理，和 C++ RAII 对象不兼容。用 std::vector 包裹它会触发析构时调用 delete[]，导致 cudaFree 被绕过，引发内存泄漏或 double-free。
- 正确做法是封装成 RAII 类型，例如：
struct UnifiedMemory { int* ptr; UnifiedMemory(size_t n) { cudaMallocManaged(&ptr, n * sizeof(int)); } ~UnifiedMemory() { cudaFree(ptr); } };- 或者用
std::pmr::vector+ 自定义memory_resource（C++26 起支持原生 UM allocator） - 误用
std::vector<int>(ptr, ptr + n)</int>不仅无效，还会在 vector 析构时尝试释放非 new 分配的内存
跨设备访问性能取决于页面迁移开销，不是所有场景都更快
统一内存靠运行时按需迁移页面，这意味着第一次 GPU 访问某页时会触发迁移，带来延迟。如果 kernel 随机访问大块内存（如稀疏矩阵遍历），可能频繁缺页，性能反不如显式 cudaMemcpy 预加载。
立即学习“C++免费学习笔记（深入）”；
- 适合场景：访问模式局部性强、迭代次数多、数据复用率高（如 stencil 计算、规约）
- 不适合场景：单次扫描、流式处理、小批量高频 launch（迁移开销占比过高）
- 可用
cudaMemPrefetchAsync(ptr, size, cudaCpuDeviceId)或cudaCpuDeviceId提前提示数据驻留位置，减少缺页中断 - NVIDIA 驱动 535+ 支持
cudaMemAdvise设置访问倾向，例如cudaMemAdviseSetReadMostly可优化只读场景
真正省事的地方不在分配，而在指针复用——只要不越界、不提前 cudaFree、不混用 new/cudaMallocManaged 指针，同一地址就能在 CPU 和 GPU 代码里无缝传递。但页面迁移逻辑藏在驱动层，出问题时往往表现为“看起来没改却结果不对”，这时候得查迁移日志或用 nvprof --unified-memory-profiling on 看实际缺页次数。
