你的问题核心出在**minV变量没有被显式初始化**，再加上不同编译选项下未初始化变量的垃圾值存在差异，以及部分编译器对OpenMP reduction的实现细节偏差，最终导致了异常结果。

详细分析 #

1. 未初始化变量的风险：你定义了int counter = 0, maxV, minV;，其中maxV和minV没有赋初始值。如果这些是局部变量，它们的初始值是未定义的垃圾值（全局变量会被零初始化，但你的输出结果更符合局部变量的特征）。
2. OpenMP Reduction的行为偏差：按照OpenMP标准，reduction(min:minV)会给每个线程创建一个私有副本，初始值为int类型的最大值INT_MAX（这也是你看到线程0的minV输出为2147483647的原因）。但部分编译器的实现可能错误地将原变量（未初始化的minV）的垃圾值作为合并的初始值，而非严格遵循标准使用单位元：
   • 如果原minV的垃圾值是0，合并时0会比所有线程的counter值都小，最终结果就是0；如果垃圾值是32767，结果就会是32767，这正好匹配你不同编译选项下的异常输出。
3. 为什么maxV和counter结果正常：
   • reduction(+:counter)的单位元是0，你已经显式初始化counter=0，完全符合要求，所以没有问题。
   • reduction(max:maxV)的单位元是INT_MIN，即使原maxV是垃圾值，通常这个值也会远小于线程的counter值，所以合并后的最大值不会受影响，结果正常。

解决方案 #

只需要在并行区域之前显式初始化minV为INT_MAX（同时建议给maxV也初始化INT_MIN，避免潜在风险），就能彻底解决问题：

#include <climits> // 需要包含该头文件来使用INT_MAX/INT_MIN

// ...

int counter = 0, maxV = INT_MIN, minV = INT_MAX; // 显式初始化所有reduction变量
bool _continue = true;
#pragma omp parallel private(id) shared(lock, _continue) reduction(min:minV) reduction(+:counter) reduction(max:maxV)
{
    // 原代码逻辑保持不变
}

额外优化建议 #

• 线程0的代码块不需要修改minV，它的私有副本已经初始化为INT_MAX，正好符合线程0不执行锁操作、不参与最小值竞争的逻辑。
• 显式初始化所有变量是良好的编程习惯，能彻底避免未定义行为，让代码在不同编译选项和编译器下都保持一致的行为。

修改后，无论使用什么编译选项，最终输出的minV都会是所有线程counter中的最小值，和你并行区域内打印的各线程minV中的最小值一致。

内容的提问来源于stack exchange，提问作者MrLukas