不能，多数情况下反而更慢甚至崩溃；并行策略需匹配数据规模、硬件能力及算法线程安全性，小数组或简单类型通常不受益。
std::execution::par_unseq 能不能直接套在 sort 上就变快？
不能，多数情况下反而更慢，甚至崩溃。并行策略不是开关，它依赖数据规模、硬件并发能力、算法内部是否线程安全。
常见错误现象：std::sort(std::execution::par_unseq, v.begin(), v.end()) 在小数组（比如 par_unseq 对 sort 的完整语义。
- 使用场景：仅当
v.size() > 10^5且元素比较/移动开销显著（如自定义类型含字符串或指针操作）时才值得尝试 - 参数差异：
par允许任务拆分但不允许多个线程同时访问同一内存位置；par_unseq允许向量化+乱序执行，但要求用户确保无数据竞争——比如不能在transform的 lambda 里修改全局变量 - 性能影响：现代 CPU 上，
par_unseq对transform或reduce效果明显；对sort效果高度依赖实现，MSVC 的并行sort比 GCC 更成熟
哪些 STL 算法真正支持并行且稳定？
支持 ≠ 安全。真正经过主流实现（libstdc++、libc++、MSVC STL）充分测试的只有几个： transform、for_each、reduce、exclusive_scan、inclusive_scan。像 find_if 或 nth_element 虽然语法合法，但行为未被广泛验证。
容易踩的坑：for_each(std::execution::par, v.begin(), v.end(), [](auto& x) { x *= 2; }) 看似安全，但如果 v 是 std::vector<:string></:string>，且字符串内部用写时复制（COW），多线程修改可能引发未定义行为——COW 在 C++11 后已被弃用，但某些旧 ABI 仍存在残留。
立即学习“C++免费学习笔记（深入）”；
- 必须检查迭代器是否为随机访问（
vector/deque可以，list不行） - lambda 不能捕获局部栈变量地址（除非是 const 值捕获），否则线程间共享栈帧会出问题
-
reduce要求二元操作满足结合律，且初始值必须与元素类型可转换；用+没问题，用-就错
为什么开了并行反而结果不对？
根本原因：你写的代码本身不是线程安全的，而 std::execution 不帮你加锁。它只负责把工作分发出去，不保证访问隔离。
典型错误现象：int sum = 0; for_each(par, v.begin(), v.end(), [&](int x) { sum += x; }); —— 这段代码在所有编译器上都产生随机结果，因为 sum 是共享可变状态，没有任何同步机制。
- 正确做法：用
reduce替代，或把中间结果存在局部 vector 再合并 - 别依赖副作用：任何修改外部变量、调用非 const 成员函数、写文件、打日志的操作，在并行策略下都是雷区
- 调试技巧：先用
std::execution::seq跑通逻辑，再换par；用 AddressSanitizer + ThreadSanitizer 编译，能立刻暴露竞态
Windows / Linux 下实际加速效果差很多，怎么回事？
不是编译器问题，是线程池和调度策略差异。Linux 默认用 pthread + 内核线程，调度粒度细；Windows 的 ConCRT（MSVC 使用）或 TBB（GCC/Clang 常配）在线程创建和负载均衡上更保守。
实测常见情况：同样 100 万整数 transform，在 8 核 Linux（GCC 12 + libstdc++）上加速比约 5.2x；在 Windows（MSVC 19.3x）上仅 3.1x，且首次运行延迟明显更高——因为默认线程池要预热。
- 解决办法：MSVC 用户可手动初始化线程池，调用
concurrency::set_max_concurrency(8)；GCC/Clang 用户建议链接-ltbb并设置环境变量TBB_NUM_THREADS=8 - 兼容性注意：
std::execution::par在 C++17 中是 optional feature，某些嵌入式 STL（如 libc++ for bare metal）完全不提供 - 别信 -O3 自动并行化：那是编译器向量化（SIMD），和
std::execution完全是两层机制，不能混用
最常被忽略的一点：并行算法的启动开销固定在几百微秒级，处理少于 10k 元素时，这开销就吃掉了全部收益。别为了“用了新特性”而并行，先跑个 perf 或 VTune 看瓶颈到底在哪。
