必须加 -fopenmp，否则 #pragma omp 指令被忽略导致纯串行执行；GCC 系列需显式启用该选项，-lpthread 无法替代；线程数可通过环境变量、omp_set_num_threads 或 num_threads 子句控制，且 parallel for 必须合并书写。
必须加 -fopenmp，否则 #pragma omp 指令会被编译器完全忽略，程序退化为纯串行执行，且不报错。
gcc/g++ 编译命令的基本写法
OpenMP 不是语言标准的一部分，而是靠编译器识别特定的 #pragma omp 指令来生成多线程代码。GCC 系列编译器（包括 gcc、g++、gfortran）需要显式启用 OpenMP 支持：
gcc -fopenmp source.c -o programg++ -fopenmp source.cpp -o programgfortran -fopenmp source.f90 -o program
漏掉 -fopenmp 时，#pragma omp parallel 这类指令会被当作普通注释跳过，所有并行逻辑失效——你看到的“没反应”“结果没变快”“线程数始终是 1”，大概率就是这个原因。
为什么不能只用 -lpthread 替代 -fopenmp
有人尝试用 gcc source.c -lpthread 来“手动模拟”多线程，这是无效的：
-
-lpthread只链接 POSIX 线程库，但不会处理#pragma omp指令，也不会自动插入线程创建/同步/负载分发逻辑 - OpenMP 的
parallel for、reduction、critical等行为，依赖编译器在编译期重写代码结构，不是运行时靠链接库就能实现的 - 强行去掉
-fopenmp却保留 OpenMP 指令，会导致静默降级，极易误判性能瓶颈位置
线程数控制：编译选项 vs 运行时设置
线程数量既可在编译时硬编码，也可在运行前动态调整，优先级从高到低为：
- 环境变量
OMP_NUM_THREADS（例如OMP_NUM_THREADS=2 ./program） - 代码中调用
omp_set_num_threads(2)（需在第一个#pragma omp之前调用） -
#pragma omp parallel num_threads(2)（仅对该 parallel 块生效） - 不指定时，默认使用逻辑核心数（
omp_get_num_procs()返回值）
注意：num_threads 子句不能写在 #pragma omp for 单独使用——它必须依附于 parallel 或 parallel for；单独写 #pragma omp for 而无 parallel，编译会报错或忽略。
常见错误现象与排查点
遇到“并行没生效”“结果错误”“段错误”时，先确认这几项：
- 编译命令是否真的包含
-fopenmp？检查历史命令或 Makefile，别信“上次能跑这次肯定行” - 源文件是否包含
#include <omp.h></omp.h>？尤其调用omp_get_thread_num()等函数时，缺头文件可能只报 warning 甚至不报 - 并行区域里是否有未保护的共享写操作？比如多个线程同时
sum += x[i]，不加#pragma omp critical或改用reduction就必然出错 - 是否误把
#pragma omp parallel和#pragma omp for拆成两行独立指令？正确写法是#pragma omp parallel for合并在一行，否则循环仍被每个线程完整执行一遍
最隐蔽的问题往往不是语法写错，而是忘了 -fopenmp —— 它不像链接错误那样明显报红，而是在背后悄悄关掉了整个并行引擎。
