std::execution::par 未加速主因是环境、数据、策略不匹配：libstdc++需-link OpenMP，libc++不支持，MSVC需/qpar；数据量＜50万基本无效；须用-O2、-pthread/-fopenmp编译并验证多线程执行。
直接上 std::sort(std::execution::par, begin, end) 几乎肯定不会变快，大概率还是串行跑——不是你写错了，是环境、数据、策略三者没对齐。
为什么 std::execution::par 调用 sort 后 CPU 占用没升、耗时没降？
这不是 bug，是标准库实现的现实约束。多数 libstdc++（GCC）默认不启用并行后端，除非你显式链接 OpenMP 或 pthread；libc++（Clang）截至 2026 年 4 月仍完全不支持 std::execution::par；MSVC 虽支持，但也得开 /qpar 且仅限部分算法。
- 运行前先检查：
std::thread::hardware_concurrency()返回 0 或 1，就别试了 - 编译必须带
-pthread（Linux/macOS）或启用并发运行时（Windows），GCC 还得加-fopenmp才可能触发线程池 - Debug 模式下，libstdc++ 会静默降级为
seq，务必用-O2以上测试 - 用
htop或任务管理器观察：若只有单核持续满载，说明并行根本没走通
什么规模的数据才值得用 par 或 par_unseq？
小于 10⁵ 元素的 std::sort 基本白搭——线程启动+分块+归并的开销远超收益。实测中，只有当 v.size() >= 500000 且元素是自定义类型（含字符串、指针、深拷贝逻辑）时，par 才开始显现加速比。
-
par_unseq对sort不仅无效，还可能崩溃：它要求比较操作无副作用、无全局状态、可乱序执行，而std::sort内部有强顺序依赖 - 真正适合
par_unseq的是std::transform、std::reduce这类纯函数式操作 - 随机访问迭代器是硬门槛：
std::vector可以，std::list或std::deque直接编译失败
怎么写才能让并行 sort 真正跑起来？
别只改一行代码。真实生效需要三步联动：数据准备 + 编译配置 + 运行时验证。
立即学习“C++免费学习笔记（深入）”；
- 数据预热：确保
v是连续内存（std::vector），且v.capacity() == v.size()，避免重分配干扰 - 编译命令示例（GCC）：
g++ -std=c++17 -O2 -pthread -fopenmp sort.cpp -o sort - 加个最小验证逻辑：
auto start = std::chrono::steady_clock::now(); std::sort(std::execution::par, v.begin(), v.end()); auto end = std::chrono::steady_clock::now();，再对比seq版本耗时 - 输出线程 ID 验证（仅调试）：
std::for_each(std::execution::par, v.begin(), v.end(), [](int&) { std::cout << std::this_thread::get_id() << '\n'; });，去重后应 ≥2
最容易被忽略的坑：内存分配和数据竞争
并行 sort 内部会频繁申请临时缓冲区，若用默认 new，多线程争抢堆锁会吃掉一半性能。更隐蔽的是：lambda 里捕获非 const 引用、调用非 const 成员函数、甚至用 std::cout，都会导致未定义行为。
- 避免在排序期间修改容器本身（如
push_back、erase），否则迭代器失效风险翻倍 - 不要在
std::sort的比较函数里读写共享变量，哪怕加了std::atomic，也破坏算法语义 - 考虑用内存池预分配：对千万级数据，
std::sort配合自定义分配器可提升 30% 吞吐量 -
par_unseq下连std::sqrt都可能出问题——某些 libc 实现的数学函数非 reentrant，得换std::sqrtf或查表
