C++ OpenMP并行编程：复杂变量应定义在循环内还是循环外？

第一种在循环内定义scratch的实现确实可能因为反复构造、析构对象产生可观的运行时开销，且开启编译优化后，编译器也不会大概率帮你复用内存、消除重复分配操作，优先选择第二种并行块内声明线程私有暂存变量的写法更稳妥。

两种写法的本质行为差异 #

• 第二种（并行块内、循环外定义scratch）的行为由OpenMP和C++标准明确保证：每个工作线程在进入并行块时仅构造1次vector<int>，完成一次大小为size的内存分配，线程负责的所有循环迭代都会复用这块内存，仅当线程退出并行块时才会析构对象、释放内存，完全匹配串行版本“一次分配、迭代间覆写复用”的逻辑，没有额外的内存管理开销。
• 第一种（循环体内定义scratch）按照C++语义，变量生命周期绑定单次循环迭代：每进入一次迭代就要调用vector构造函数申请堆内存，迭代结束立刻调用析构函数释放内存。当循环次数count较大、size数值不小时，反复的堆分配/释放操作本身就会产生明显开销，多线程场景下堆分配器的内部锁竞争、线程本地缓存查找成本还会进一步放大这个损耗。

为什么不能指望编译器优化掉重复分配 #

编译器要把循环内的vector分配提到循环外复用，必须满足非常严苛的前提：它需要100%证明f和g两个函数不会把scratch的内存地址泄露到单次迭代的作用域之外，且不同迭代的scratch生命周期不存在交叉。
实际场景下这个优化几乎很难稳定触发：

1. 如果f、g的定义不在当前翻译单元（比如是其他源文件实现的函数、动态库导出函数），编译器根本看不到两个函数内部对scratch的操作，完全无法确认是否存在地址泄露的可能，出于正确性保证绝对不会贸然修改内存分配的位置。
2. 即便f、g可以被内联分析，堆分配属于带副作用的库函数调用，编译器对这类操作的优化向来非常保守。只有极其简单的测试用例可能触发提升，只要代码存在分支、间接调用等稍复杂的逻辑，优化就会失效，根本不存在“开优化就大概率复用”的情况。
3. 就算底层堆分配器对相同大小的内存块做了线程本地缓存，每次迭代还是要付出vector对象初始化/析构、分配释放函数调用的固定开销，性能还是弱于一次分配的写法，且这个行为完全依赖堆分配器的具体实现，换个运行环境表现就可能不一样，根本不可控。

不要赌编译器会做这个优化，C++和OpenMP标准从来没要求编译器做这种跨生命周期的内存提升，不同版本、不同厂商的编译器表现差异极大，你在本地测试可能某个编译器版本碰巧触发了优化，换个编译环境就可能出现明显的性能回退。

实践建议 #

如果你的需求就是每个线程持有一块独立暂存空间、迭代之间仅覆写内容不需要保留历史数据，直接使用第二种写法即可。这种写法逻辑清晰、性能稳定，完全不依赖编译器的激进优化，没有任何语义问题。

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