必须显式同步，否则 cudaMemcpy 读到未计算的脏数据；加法 kernel 需用 global 标记、无返回值、通过线程索引计算并越界检查。
为什么直接用 cudaMemcpy 传数组却得不到正确结果？
常见错误是只调用 cudaMemcpy 把数据从主机拷到设备，但没等 GPU 内核执行完就立刻把结果拷回主机——此时 cudaMemcpy 默认是同步的，但内核本身是异步的，结果就是读到未计算的脏数据。必须显式同步，或改用 cudaMemcpy 的同步变体（如 cudaMemcpyDeviceToHost）配合 cudaDeviceSynchronize()。
- 别依赖“写完
kernel>>()就算执行完了”，它只是启动请求 -
cudaMemcpy从设备读回主机时，若没同步，可能读到旧值或随机内存 - 简单验证：在 kernel 后加一句
cudaDeviceSynchronize();，再 memcpy，就能看到正确结果
怎么写一个能被 GPU 正确调用的加法 kernel？
GPU kernel 不是普通函数，它不能有返回值、不能递归、参数只能是基本类型或指针，且需用 __global__ 标记。每个线程处理一个数组元素，靠 threadIdx.x + blockIdx.x * blockDim.x 算出全局索引，还要检查是否越界——因为启动配置的线程数可能多于数组长度。
__global__ void add_arrays(float* a, float* b, float* c, int n) {
int idx = threadIdx.x + blockIdx.x * blockDim.x;
if (idx < n) {
c[idx] = a[idx] + b[idx];
}
}- 必须加
if (idx ，否则当 <code>n不是 block size 整数倍时，会越界写入 - 不要在 kernel 里用
printf调试，输出不可靠；可用cudaGetLastError()检查 launch 错误 - 参数传的是指针，不是数组引用或 std::vector —— GPU 无法直接访问主机 STL 容器
block 和 grid 尺寸怎么选才不卡死也不浪费？
选太小（比如 blockDim = 1），线程太少，GPU 大量计算单元闲置；选太大（比如超硬件限制），launch 失败报错 too many resources requested for launch。主流 GPU 通常支持每 block 最多 1024 个线程，常用 256 或 512；grid size 则由数组长度和 block size 推导而来。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 推荐写法：
int blockSize = 256;，int gridSize = (n + blockSize - 1) / blockSize; - 别硬写
gridSize = n / blockSize，整除会丢掉余数线程 - 用
cudaGetDeviceProperties()可查具体卡的 maxThreadsPerBlock，但日常开发用 256 基本通用
为什么 malloc 分配的内存不能直接给 GPU 用？
malloc 返回的是主机端可分页内存，GPU 访问慢且不保证一致性；必须用 cudaMalloc 分配设备内存，或用 cudaMallocHost 分配“页锁定”主机内存（适合频繁传输的小数据）。混淆这两者会导致 cudaMemcpy 失败，报错 invalid argument 或 memory access violation。
立即学习“C++免费学习笔记（深入）”；
- 设备指针必须来自
cudaMalloc，主机指针必须来自malloc或cudaMallocHost - 传错指针类型（比如把 host 指针传给 kernel）不会编译报错，但运行时崩溃
- 记得配对释放：
cudaFree对应cudaMalloc，free对应malloc
实际跑通的关键点就三个：用 cudaMalloc 分配设备内存、写带边界检查的 <strong>global</strong> kernel、kernel 后加 cudaDeviceSynchronize()。其余都是围绕这三件事做安全校验和资源管理。
