加#pragma omp parallel for易出错，因未加reduction会导致sum等变量数据竞争，每次运行结果不同或偏小；循环依赖、共享i/o、错误线程数设置等亦引发崩溃或性能下降。
加一行 #pragma omp parallel for 就能并行，但不加 reduction 或乱设线程数，大概率结果错、性能降、甚至崩溃。
为什么 #pragma omp parallel for 一加就出错？
最常见现象是：程序每次运行结果不同，或 sum 值明显偏小/偏大。根本原因是多个线程同时读写同一个变量（比如 sum += a[i]），产生数据竞争——这不是“偶尔出错”，而是未定义行为，C++ 标准不管它怎么崩。
- 循环体里不能有跨迭代依赖：
a[i] = a[i-1] + 1这类写法直接禁用 - 不能调用不可重入函数：
rand()是全局状态，必须换std::mt19937+private - 不能做 I/O：
std::cout并发输出会乱序甚至卡死，调试时用omp_get_thread_num()打印线程 ID 更安全 - 循环变量必须是整型、步长为常量（
i++或i += 2），且上下界在进入循环前已确定
怎么安全地累加、计数、写数组？
核心就两条：用 reduction 处理归约操作，用 private 隔离线程私有状态。
- 累加、求最大值、逻辑与等可归约操作：必须写
#pragma omp parallel for reduction(+:sum)——+是操作符，sum是变量名，漏掉括号或符号会编译失败 - 每个线程需要独立对象（如随机数引擎、临时 buffer）：加
private(rng)，注意rng必须在循环外声明且可默认构造 - 如果变量初始值要传给每个线程副本，用
firstprivate(x)；如果只想要最后一次迭代的值，用lastprivate(i)——别把它们和private混用 - 绝对不要靠
#pragma omp critical保护普通累加：它串行化关键区，性能比单线程还差
线程数和调度策略怎么设才不拖慢？
默认线程数常等于逻辑核心数（含超线程），但对纯计算任务，超线程反而可能降低吞吐。实测中，8 核 CPU 设 OMP_NUM_THREADS=8 通常比 =16 更稳。
- 环境变量优先级高于代码：
export OMP_NUM_THREADS=8（Linux/macOS）或set OMP_NUM_THREADS=8（Windows）比omp_set_num_threads(8)更可靠，后者必须在首个并行区域前调用 - 均匀负载（如所有迭代耗时接近）：用默认静态调度（
schedule(static)），开销最小 - 不均匀负载（如部分迭代要查表、部分要解方程）：改用
schedule(dynamic, 32)，32 是 chunk size，太小增加调度开销，太大导致负载不均 - 永远用
omp_get_max_threads()检查当前生效线程数，别硬编码假设
编译和头文件容易漏掉什么？
缺 #include <omp.h></omp.h> 会报 omp_get_thread_num 未声明；不加编译选项则 #pragma 被完全忽略——程序照常跑，但仍是单线程，你却以为“已经并行了”。
- GCC / Clang 必须加
-fopenmp，不是-lopenmp（后者是链接选项，通常自动追加） - MSVC 用
/openmp，注意不是/Qopenmp（那是旧版） -
omp.h不是标准头文件，某些精简版容器镜像可能没装libgomp1或libomp-dev，编译时报 “omp.h: No such file” 就得先装包 - 若用 CMake，记得加
find_package(OpenMP)和target_link_libraries(... ${OpenMP_CXX_LIBRARIES})，否则链接阶段可能失败
真正难的从来不是加那行 #pragma，而是确认循环体里没隐藏的全局状态、没伪共享的缓存行冲突、也没被编译器优化掉的副作用——这些地方不会报错，但会让加速比从 5× 跌到 1.2×。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
