std::execution::par常无加速效果，因并行开销可能超过收益；需同时满足数据量大（通常>数万元素）、单次操作计算量足、迭代器支持随机访问三个条件才有效。
std::execution::par 为什么经常没效果？
直接用 std::execution::par 调用 std::sort 或 std::transform 却发现耗时没变，甚至更慢——这不是你代码写错了，而是并行开销压倒了计算收益。STL 并行策略不自动“加速一切”，它只在满足三个隐性条件时才真正分发到多核：数据量够大（通常 > 数万元素）、每项操作有足够计算量（不能是纯内存拷贝）、迭代器支持随机访问（std::vector 可以，std::list 不行）。
实操建议：
- 先用
std::chrono测单线程耗时，再测并行版；若单次调用 - 避免在小容器（如 size std::execution::par
- 确认编译器支持：GCC 9+、Clang 10+、MSVC 2019 16.10+，且需开启
-pthread（Linux/macOS）或启用并发运行时（Windows）
std::execution::par_unseq 和 par 的关键区别在哪？
std::execution::par_unseq 不只是“更并行”，它允许编译器对同一段数据做 乱序向量化 + 多线程混合优化，比如把 std::transform 拆成 SIMD 批处理 + 线程分块。但代价是：算法内部不能有顺序依赖，也不能调用非 const 成员函数或修改共享状态。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 用
par_unseq调用含std::cout 的 lambda → 输出乱序甚至崩溃（未定义行为） - lambda 中修改外部变量（如
int count = 0; [&] { ++count; }）→ 数据竞争，结果不可预测 - 传入的函数对象有内部可变状态（如自增计数器）→ 行为未定义
安全用法示例：
std::vector<int> a(100000, 1), b(100000);
std::transform(std::execution::par_unseq,
a.begin(), a.end(),
b.begin(),
[](int x) { return x * x + 2 * x + 1; }); // 纯函数，无副作用如何判断某个 STL 算法是否真的并行执行了？
没有运行时 API 能直接返回“当前用了几个线程”，但可通过三类证据交叉验证：
- 观察 CPU 使用率：用系统监控工具（
htop、Windows 任务管理器）看是否多个核心持续跑满（注意排除其他进程干扰） - 加日志打点（仅调试）：在 lambda 内用
std::this_thread::get_id()记录线程 ID，输出去重后的数量（注意别让 IO 拖慢并行） - 强制限制线程数测试：GCC 下设置环境变量
export GOMP_THREADS=2，再对比耗时变化；若耗时几乎不变，说明根本没走并行路径
注意：某些标准库实现（如 libstdc++）在 debug 模式下会静默降级为串行，务必用 -O2 或更高优化等级测试。
vector 和自定义分配器会让并行失效吗？
会。std::vector<bool></bool> 是特化模板，其迭代器不是真正的随机访问迭代器（operator[] 返回 proxy 对象），导致所有并行算法在它身上退化为串行调用，且编译期可能报错或静默失败。
自定义分配器本身不阻止并行，但若其 allocate/deallocate 有锁或全局状态，就会成为性能瓶颈，抵消并行收益。
实操建议：
- 需要并行处理布尔数据时，改用
std::vector<uint8_t></uint8_t>或std::vector<:byte></:byte> - 自定义分配器中避免锁；如需线程安全，优先用
thread_local缓存池，而非全局互斥 - 对
std::deque、std::forward_list等非随机访问容器，并行算法直接编译失败（SFINAE 排除），不会静默退化
并行策略的边界很实在：它不解决算法复杂度，也不掩盖数据竞争。真正起效的前提，是问题本身具备可分割性、无强顺序约束、且开销值得调度成本。漏掉其中任何一条，par 就只是多开了几个线程而已。
