std::execution不是“写了就能并行”的开关，而是需严格匹配编译器支持、数据规模（≥10⁶）、迭代器类型（仅随机访问）及无副作用操作的执行提示；libstdc++需-link openmp、libc++不支持、MSVC需/qpar且sort长期无效，小数据或调试模式下必降级为seq。
直接说结论：std::execution 并不是“写了就能并行”的开关，它是一组需严格匹配环境、数据特征与算法语义的执行提示；多数情况下，std::sort(std::execution::par, ...) 不加速，甚至崩溃，根本原因不在代码，而在编译器支持、运行时配置和操作本身是否满足策略约束。
为什么 std::execution::par 调用后 CPU 占用没变、耗时没降？
这不是你写错了，是标准库实现不自动生效。真实情况如下：
-
libstdc++（GCC 默认）默认禁用并行后端：必须显式链接-fopenmp或-pthread，否则静默回退到seq -
libc++（Clang 默认）截至 2026 年 4 月仍完全不支持std::execution::par和par_unseq，编译通过但运行时无效 - MSVC 需启用
/qpar且仅对部分算法（如std::for_each、std::transform）生效，std::sort在 MSVC 中长期不支持par - Debug 模式下，几乎所有实现都会强制降级为
seq；必须用-O2或更高优化等级测试 - 运行前先验证硬件并发数：
std::thread::hardware_concurrency()返回 ≤1，则并行无意义
std::execution::par_unseq 实际能用在哪？别乱塞给 std::sort
par_unseq 要求操作满足「无副作用、可重排、无全局状态」，而 std::sort 内部有强顺序依赖和分段归并逻辑，强行传入不仅不加速，还可能触发未定义行为（如段错误或结果错乱）。
- 真正安全可用的场景：纯函数式遍历类算法，例如
std::transform、std::reduce、std::for_each - 示例（安全）：
std::transform(std::execution::par_unseq, v.begin(), v.end(), v.begin(), [](int x) { return x * x; }); - 禁止场景：
std::sort、std::stable_sort、任何含自定义比较器且访问静态变量/全局计数器的操作 - 注意迭代器要求：只接受随机访问迭代器；
std::list、std::deque直接编译失败
怎么验证并行真跑起来了？别只看代码
光改一行参数毫无意义。必须三步联动验证：
立即学习“C++免费学习笔记（深入）”；
-
编译命令必须带并发支持：GCC 示例：
g++ -std=c++17 -O2 -pthread -fopenmp main.cpp -o main -
数据规模要够大：小于 50 万元素的
std::vector<int></int>基本无收益；实测v.size() ≥ 1'000'000且元素为自定义类型（含构造/析构开销）时，par才开始显现优势 -
运行时观测必须交叉验证：
- 用
htop或任务管理器确认多核同时满载（非单核 100%） - 加线程 ID 输出调试：
std::for_each(std::execution::par, v.begin(), v.end(), [](int&) { std::cout ，去重后应 ≥2 - 用
std::chrono对比seq与par版本耗时，差值需显著（如 30%+）才可信
- 用
最容易被忽略的底层坑：内存布局与数据竞争
并行算法不关心你有没有锁，它只信任你的操作是无状态的。常见隐形陷阱：
-
std::vector必须预分配好空间：v.reserve(N); v.resize(N);，否则内部push_back或重分配会引发数据竞争 - 若 lambda 中捕获了外部变量（尤其是非 const 引用），且该变量被多个线程读写，就是典型数据竞争——
par_unseq下尤其危险，因编译器可能重排执行顺序 - 避免在并行循环中调用
std::cout、malloc、time()等非 reentrant 函数；它们不是线程安全的，会导致输出混乱或性能骤降 - 使用
std::atomic替代全局计数器，或改用std::reduce+ 合并器，而非手动累加
