企业官网建设流程全解析

“并行算法在STL中的应用”是我这两年一直想写的一个题目。原因很简单：C++17标准把并行算法正式纳入STL，std::sort、std::transform、std::for_each这些老面孔一夜之间可以“开多线程跑”，这是标准库几十年来最大的一次性能扩展。但真正上手的人会发现，事情远没有“加一个执行策略参数”那么简单——策略怎么选、数据竞争怎么避、粒度多大才有收益、为什么开了并行反而变慢，这些坑我全踩过。这篇文章不打算给你堆API文档，而是把我在模拟项目X里从串行迁移到并行算法的完整过程、性能数据和失败教训一次说清楚。

1. MVP开门见山：并行STL到底改变了什么

1.1 从算法签名变化看标准库的设计思路

先看最直观的东西。在C++11/14时代，你想对一个vector做变换，写法是这样的：

std::transform(src.begin(), src.end(), dst.begin(), [](double x){ return x * 2.0; });

到了C++17，只需多传一个参数：

std::transform(std::execution::par, src.begin(), src.end(), dst.begin(), [](double x){ return x * 2.0; });

多出来的std::execution::par就是并行执行策略（parallel execution policy），它告诉标准库的实现：“这个算法你可以用多个线程来跑。” 就这么一个小改变，背后却牵动了一系列标准库基础设施的演进——不只是某一个算法加了重载，而是几十个算法全部加了一套带执行策略的版本。包括但不限于for_each、all_of/any_of/none_of、count_if、find_if、copy_if、transform、reduce、sort、partial_sort、remove、unique、merge、nth_element，以及一堆scan操作（inclusive_scan、exclusive_scan）。

为什么标准委员会选择“重载”而不是“新造一套并行库”？这个设计决策我读标准草案时印象很深。他们希望并行能力像“库存货”一样叠加在已有算法之上，开发者在迁移时不需要改变算法名称、不需要学习新容器、也不需要重构代码逻辑——只需要在调用点做局部修改，并且自己能证明数据访问是安全的。这就降低了很多团队的迁移门槛。换句话说，并行STL是一条“低成本入场”的路径：先保住已有代码的算法语义，再通过执行策略逐步释放多核性能。

1.2 三种执行策略的安全级别与语义约束

C++17标准定义了三种执行策略，C++20又加了一种std::execution::unseq，我先用一张表把它们的核心区别说清楚：

这里重点说说par和par_unseq的区别，这是很多人忽略的点。par_unseq不仅允许实现把循环拆分到多个线程，还允许在一次迭代内部使用SIMD指令同时对多个元素做操作，甚至允许把循环体里的代码交错执行。正因为有这个“交错”的可能性，如果你在仿函数里用了std::mutex或者std::atomic，严格来说就是违反par_unseq约束的行为——标准说算法可以“unsequenced”地调用函数，这意味着同一线程内对atomic的操作顺序都可能被打乱，通常编译器不会报错，但结果是未定义的。所以我的原则是：没有充分理由，一律用par，不用par_unseq。par_unseq那点SIMD收益，在大多数业务代码里远小于它带来的正确性风险。

par策略本身也有一个隐含要求：算法执行期间，元素访问不能产生数据竞争（data race）。如果两个线程同时读一个元素，没问题；如果多个线程写同一个元素，不行；如果一个线程读写、另一个线程也读写同一元素，也不行。标准委员会刻意没有把“数据竞争检查”作为编译器的强制义务，所以这个责任的绝大部分落到了调用者身上。很多人第一次用并行STL写出跑飞的结果，根源就在这里。

2. 并行策略背后的技术细节与选型逻辑

2.1 标准库实现者的困境：自动并行化为什么这么难

其实如果只是“把循环拆成多个线程跑”，很多编译器早就能做到一部分了——比如OpenMP的#pragma omp parallel for。那标准库为什么还要专门做一套并行算法？核心原因是，STL算法不仅仅是“循环”，它们还有复杂的内在依赖顺序。拿std::sort来说，快速排序的分区操作天然是递归分裂的，两个分区之间没有任何数据依赖，适合并行；但是分区内部的合并、基准元素的选择、迭代器的移动，每一步都需要精心设计才能安全地并行化。

更麻烦的是通用算法（generic algorithm）要求对“任意类型的迭代器、任意仿函数”都成立。实现者不能假设迭代器是随机访问迭代器，不能假设元素类型没有副作用，也不能假设仿函数是可重入的。这就导致标准库实现必须做一个“兼容层”：能并行就并行，不能并行就退回串行。比如在某个知名标准库实现里，std::execution::par版的find_if就有一段逻辑：如果元素数量大于某个阈值，就开线程并行查找；否则直接走串行路径。这不是“偷懒”，而是经过测试验证的务实策略——并行本身的调度开销有时候比串行还高。

再说一个容易忽略的层面：并发时“仿函数对象”本身是被多个线程共享的。例如你给std::for_each传一个带内部状态的仿函数，串行时代码可能是这样的：

struct Accumulator { int count = 0; void operator()(int x) { if (x > 0) ++count; } }; Accumulator acc; std::for_each(begin, end, acc);

这个代码在串行下完全正常，但换成std::execution::par之后，标准允许实现把仿函数复制到多个线程各持有一份，于是每个线程里的count是独立的，最后你拿到的acc.count根本对不上总数。这不是“实现者的错”，而是标准的语义要求：带并行策略时，仿函数必须能够安全地多副本运行、并且外部不依赖它操作单个共享对象的副作用。如果一定要收集计数结果，正确的做法是用std::atomic或reduce这类为并行而生的算法，而不是for_each加共享状态。

2.2 选择恰当算法的两个关键判断：数据粒度与仿函数性质

在动手迁移前，我会先问自己两个问题，它们决定了一个算法适不适合并行化、以及需要投入多少改造工作量。

第一个问题是“数据粒度够不够大”。这里我习惯算一个简单估算：把单个元素的计算量和整个区间的长度乘起来，再和线程调度开销对比。经验公式大致是这样的：单元素计算耗时 × 元素数量 > 10微秒，并行化往往才值得。举个反例，如果你只是对一个vector<int>做std::copy，单元素操作约等于一次内存拷贝，哪怕数据有几百万个元素，内存带宽往往是瓶颈，并行不但不会加速，反而会因为缓存竞争和线程调度引入额外开销。我自己在一次基准测试里就出现过这样的情况：对8MB的vector<int>做并行copy，耗时比串行多了接近30%。原因很简单，内存拷贝的瓶颈在DRAM带宽和缓存层级，CPU核心再多也没用，开线程反而把一个小操作拆成了很多个需要同步的任务。

第二个问题是“仿函数安不安全”。如果一个仿函数是无状态的（除了参数什么都不碰），或者它访问的对象彼此完全独立，那基本可以放心交给并行策略。如果一个仿函数依赖了以下任何一种东西：全局可变变量、静态局部变量、外部容器的非原子修改、随机数生成器的共享状态、再加一个std::rand()，那我就会先做重构。重构的方式一般有两种：要么用局部副本、最后再合并，要么直接用并行STL里专门做此类合并的算法（比如reduce和transform_reduce）。我在模拟项目X里就重构过一个基于全局计数器统计命中率的代码块，改造后不仅并行化失败的问题消失了，还顺手把原先一个多余的外部依赖给删掉了。

3. 实操过程：从串行算法迁移到并行算法的完整记录

3.1 运行环境与工具链准备：编译器、标准库链接与C++版本

这里先把我当时的运行环境列出来，方便有需要的读者对照复现：

这里特别强调一下链接问题，这是初学者最容易卡住的地方。C++17标准的并行算法是分层设计的：标准只定义了算法接口和执行策略语义，但“谁来真正创建线程、如何调度任务”是由具体实现决定的。在GCC的libstdc++里，并行算法后端默认选择TBB（Threading Building Blocks），而不是自己造调度器。如果你只是写了std::execution::par，不加-ltbb链接参数，很可能会遇到链接错误，类似“undefined reference to__gthread_active_p”或者TBB符号找不到。不同发行版、不同版本、不同编译器，链接方式可能略有差别，但核心思想是一样的：要么安装并链接TBB，要么确保标准库实现支持另一个后端（同系列的编译器链路中有时会自带其他后端选型）。

我编个简单的测试程序验证工具链是否就绪：

#include <algorithm> #include <execution> #include <vector> #include <iostream> int main() { std::vector<int> v(1000000); std::iota(v.begin(), v.end(), 0); std::for_each(std::execution::par, v.begin(), v.end(), [](int& x){ x = x * 2; }); std::cout << v[100] << "\n"; return 0; }

编译参数是：

g++ -std=c++17 -O2 -ltbb -o par_test par_test.cpp

注意-ltbb放在目标文件之后（实际中GCC工具链对库顺序有约定，简单项目这样写通常够用；复杂工程建议通过构建系统的链接配置处理）。如果程序输出的200和预期值一致，说明并行执行策略已经正确对接到了TBB后端。

3.2 数据划分、任务调度与边界处理的实操细节

接下来进入真正“并行化思维”的训练。串行代码往往默认整个区间是一个不可分割的整体：先算前一半，拿结果去算后一半。而并行STL的语义是“把区间切成若干块，每块交给一个线程”。所以你在编写仿函数时，一定不能依赖于任何跨元素的顺序关系，特别是不能依赖“前面元素的结果影响后面元素的计算”。这类依赖在串行里可能是隐性存在的，比如某个累加函数里悄悄用了一个前一循环写入的临时变量。

我遇到过一个非常隐蔽的例子。某同事把一段手写循环迁移到std::transform，仿函数内部引用了全局数组g_table[level]，而这个level是在循环体外部的状态变量，每次迭代都根据前一次的结果更新。串行时完全正确，改成par后，由于各线程访问level的顺序不确定，g_table的索引经常错位，结果出来后一大片数据是错误的。排查了半天，最后还是靠“把这种有状态依赖的循环改成‘先无状态变换、再做有状态化简’两段式”才解决。这类教训我觉得才是迁移并行STL最核心的一课：有状态迭代的顺序依赖必须显式地拆解掉，或者干脆放弃并行化那一段代码。

实操中，我还发现一个关于数据局部性的技巧：并行切换对超大数据集更友好，但需要注意内存分配方式。为了让多个线程尽可能少地争抢同一个内存页，我会尽量用“连续、独立、足够大”的容器，避免在仿函数内频繁动态分配vector。如果服务器内存够大，还可以考虑预分配输出容器，再用transform直接写，省掉反复push_back带来的锁竞争。

3.3 一个真实迁移案例：某跨平台系统的图像预处理模块

为了不显得空谈理论，我讲一个在模拟项目X里做的具体案例。项目是一个图像预处理模块，输入是一组RGB图像文件，每张图需要做颜色空间转换、滤波、归一化。原始的串行代码里有三个阶段，每个阶段用for循环遍历所有像素，最耗时的部分是高斯滤波，单张图大约耗时18毫秒左右，整个批次大概200张图，总耗时约3.6秒。业务侧反馈说这个耗时对实时性要求不够，于是我们考虑并行化。

第一阶段先用std::for_each把所有图像路径读入内存，这一步本身是IO密集型，并行时效果有限，遂保留串行。第二阶段对内存中的图像数据做颜色转换和滤波，这里用std::transform(std::execution::par, ...)处理整张图的所有像素。由于不同像素之间的滤波只依赖原图对应位置的邻域数据，输出像素之间是独立的，所以数据竞争不存在，可以放心并行。改造后单张图的滤波耗时从18毫秒降到了约4.5毫秒，接近线性加速。第三阶段归一化用std::transform配合并行策略，也是安全的。三段加在一起，200张图的整批处理时间从3.6秒降到了1.1秒左右，收益非常明显。

这个案例有什么可以给你抄作业的点？第一，IO部分别碰并行，磁盘瓶颈决定了你开线程也没用。第二，像素级并行对“CPU计算密集、数据独立、无共享状态”的任务效果最好，这里几乎是教科书式适配。第三，输出容器预先resize好，避免在并行仿函数里触发分配器锁竞争。我把这些点写下来，希望你迁移自己的代码时也能提前识别哪些环节值得并行、哪些环节只是“看起来值得”。

4. 性能洞察：并行STL的收益边界与适用场景

4.1 基准测试设计与结果解读：加速比、调度开销与缓存效应

做性能分析不能拍脑袋。我通常会把测试拆成几组：小数据量（1千元素）、中数据量（10万元素）、大数据量（1000万元素），然后分别测串行sort、并行par、并行par_unseq三者的耗时。这里给出我在模拟项目X里对std::sort做的一组测试结果（以相对串行的加速比展示）：

第一行数据我特意留在这里，它是很多“并行STL没用”论调的来源：小数据量并行反而变慢。原因很直接，启动线程任务、同步、等待结果的开销是固定的，几十微秒级别。当排序本身只要80微秒时，并行调度开销是纯浪费。第二行开始，并行优势就显现了，100,000个元素时接近3.2倍加速。第三行10M元素时，加速到5倍左右，离8核理论加速比还有距离，这主要是内存带宽和排序算法内部不可避免的串行部分在拖后腿。之后我把par_unseq也测了，发现它相比par并没有带来显著优势，某些场景甚至略慢，所以后续统一用par。

这里还有一个特别值得说的经验：不要只测算法耗时，还要看内存分配耗时。并行sort的实现靠TBB调度一堆子任务，这些任务内部可能需要临时缓冲区，如果系统内存压力大，任务调度可能触发频繁的页分配，导致耗时抖动。我在一次压测中遇到并行排序总耗时忽高忽低的情况，后来发现是另一个进程在同时吃内存，触发swap导致的。后来我把测试环境内存余量控制住，耗时曲线才稳定下来。

4.2 哪些STL算法适合并行、哪些不适合

根据我自己的测试和阅读实现源码的经验，可以把并行STL算法按“收益潜力”粗略分成三档：

这里重点敲一下find_if：它本身有短路语义，找到第一个匹配元素就可以提前停止。并行实现为了做到“多个线程同时找”，势必要引入一种“全局发现标志”——任何线程找到后要通知其他线程停止。这个过程很难做到零成本，数据量小的时候收益是负数。我在实测中，100,000个整数找某个值，par只比串行快了不到20%，而transform在同样数据量下能快3倍。所以你必须知道哪些算法是“为并行而生”的，哪些只是“兼容并行”的。

另一个容易误用的场景是std::accumulate。accumulate是顺序累加，但很多团队一看名字觉得“并行化不是理所当然的吗？”事实是，标准的并行对应物是std::reduce，而不是给accumulate加执行策略。为什么？因为accumulate的语义要求严格从左到右、保持二元运算的精度和顺序，而reduce允许乱序、允许结合律不保证时的差异（只要运算满足结合律）。如果你想加速求和，要用std::reduce(std::execution::par, ...)或者std::transform_reduce。这里另一个隐含问题是浮点加法不满足结合律，并行reduce可能因为分组顺序不同得到和串行不一样的结果，但通常差异在可接受范围内；如果你对结果严格敏感，要么保持串行accumulate，要么引入定点运算。

5. 避坑实录：并行STL使用中的常见问题与调试手段

5.1 数据竞争、仿函数复制与异常安全的三重陷阱

我在前面已经提过数据竞争，这里再展开讲一些具体“事故现场”。最典型的错误是对同一个vector“边读边写”，只是读和写的元素位置看起来不冲突。比如下面这段代码：

std::vector<double> data(n, 1.0); std::for_each(std::execution::par, data.begin(), data.end(), [&](double& v) { double neighbor = data[(index_of(v) + 1) % n]; // 访问邻居 v = v + neighbor; });

如果你无法保证每个线程访问的后一个元素和前一个元素不在同一缓存行上，这个代码就存在数据竞争的可能——线程A在读邻居元素时，线程B可能正在写同一个元素。更麻烦的是，这种bug不是必现的，它依赖于线程调度和缓存时序，可能跑一万次错一次。我建议的做法：在仿函数内只访问“当前迭代元素”和“预先准备好的只读数据”，凡是需要跨元素访问的，一律先复制出一份只读快照，或者把算法拆成两个独立阶段。

仿函数复制是第二个大坑。标准允许实现把传入的仿函数拷贝到不同线程，如果你的仿函数内部持有一个shared_ptr指向某个可变结构，那多个线程同时改这个结构也会出现竞争。我有次排查一个偶发的计数错误，花了整整一天，最后发现代码里std::ref没有正确使用，导致每个线程用的其实是同一个Accumulator对象，两个线程同时++count，结果就是丢失更新。解决方法是让每个线程持有自己的累加副本，最后把结果合并；更干净的写法是用std::transform_reduce加一个合并lambda。

异常安全这个问题更冷门但非常重要。标准规定：带执行策略的算法如果执行期间仿函数抛出异常，会调用std::terminate终止程序，而不是像串行算法那样把异常传播给调用者。这和很多人的直觉相反——以为并行只是“线程里抛异常然后捕获”。实际上标准认为并行环境下异常传播的语义太复杂，谁也不知道任务在哪个线程、什么时机抛的异常，强行捕获很容易破坏任务调度器的内部状态。所以我的铁律是：并行仿函数内部保证不抛异常，必要的话用返回值或错误码表达失败。如果一个操作真的可能失败（例如分配内存失败），就提前在并行前预留好资源，或者用串行路径做一次预处理。

5.2 调试思路与性能剖析工具：如何定位并行化瓶颈

调试并行STL的代码，最痛苦的一件事是：错误往往伴随着极端条件才能复现，gdb单步调试基本帮不上忙。我自己的调试流程一般是这么走的：

第一步，加一个“串行对照模式”。在开发期把执行策略参数化提出来，比如定义一个编译期开关，#ifdef PAR_MODE用std::execution::par，否则用std::execution::seq。先用串行模式跑一遍，确定算法逻辑和结果基准；再切到并行模式，比对结果是否一致。这能迅速把“并行引入的数据竞争”和“算法本身的逻辑bug”区分开。

第二步，用ThreadSanitizer（线程消毒器）检测数据竞争。GCC和clang都支持-fsanitize=thread，它能捕捉到对共享内存未加保护的真实竞争事件。注意它也会误报一些无害的原子操作，但对绝大多数情况非常有效。我在模拟项目X里用这个工具抓到过一个人很隐蔽的竞争：一个全局计数器在par模式下被多个线程增加，但加的是整数非原子变量。不跑检测工具时，它一周可能只出现一次错误结果，ThreadSanitizer一开，几秒钟就报警了。类似的情况我也在别的项目碰到过多次，所以我强烈建议：任何并行代码上线前必须过一遍sanitizer。

第三步，用性能剖析工具确认瓶颈在哪。我推荐先在优化级别关闭的情况下（-O0）跑通逻辑，再开-O2看性能。如果并行加速比小于2，可以用perf stat看任务切换次数、缓存缺失率、分支预测失误率；也可以用TBB自带的工具或Intel的剖析器观察线程活动波形。有一次我调一个并行transform，加速比只有1.2倍，perf显示cache-misses极高，一看发现数据结构按行存储但算法按列访问，缓存的局部性全毁了。改成按列连续存储后，加速比直接跳到3.4倍。

5.3 常见问题速查表

下面这表算是我个人经验的浓缩，也可以当深水区排查手册：

6. 工具链与生态：编译器、后端与标准演进

6.1 三大编译器对并行STL的支持现状对比

并行STL虽然进了C++17标准，但标准只规定了接口，没有必须用哪个线程库。所以编译器实现的支持程度、默认后端、开启方式各不相同。以我比较熟悉的三大编译器为例：

GCC标准库（libstdc++）从GCC 9开始提供并行算法实现，默认依赖TBB。只要TBB库可用，std::execution::par开箱即用，这也是我日常最常用的组合。LLVM的C++标准库（libc++）在很长一段时间里只支持seq策略，直到较新版本才逐渐补全并行执行策略，而且也要依赖TBB或其他后端。MSVC方面，微软的STL在Visual Studio 2019之后对并行STL支持很积极，Windows下一般不需要额外链接外部线程库，实现会自己调度线程。不过MSVC对par_unseq的支持历史比较特殊，部分版本里它和par没有明显区分。你有跨平台需求的话，建议做一张“编译器×策略支持矩阵”并配上CI上的自动化测试，避免代码在某个环境链接不过或运行异常。

不同编译器对“多少个线程参与并行”的策略也不同：有的默认启动和硬件线程数相同的worker，有的采用两层嵌套调度（先拆块、再任务窃取）。这些细节意味着同一份代码在不同平台上可能表现出完全不同的耗时曲线，所以我做性能测试时，会刻意把目标平台、编译器版本、TBB版本全记录下来，否则没法对比分析。这也是为什么我前面示例里反复提到“环境是GCC 11.3、TBB 2021.x”。

6.2 并行STL与任务调度后端的关系：以TBB为例

为什么总是反复提到TBB？因为它是目前很多标准库实现后端的事实标准。TBB（Threading Building Blocks）提供了线程池和任务调度器；并行STL的算法只是“描述计算依赖关系”，实际把任务贡献给线程池、处理任务窃取等，全部由TBB完成。它有几个核心设计：任务队列是工作窃取（work stealing）的，空闲线程会主动从别的线程队列尾部“偷”任务来执行，这让负载更加均衡；还会维护任务依赖关系，避免不必要的等待。

理解这层关系对你的帮助是巨大的。当你在代码里遇到“并行STL在某个环境表现意外”，很可能不是算法问题，而是线程池的调度策略或绑定方式问题。比如TBB默认不会把线程绑定到特定CPU核心，如果同一台机器上同时跑两个使用并行STL的进程，它们可能互相争抢核心，导致加速比下降。我做过一个测试：同时跑两个并行排序任务，各自加速比都只有单跑时的70%。这说明并行STL的全局加速上限还受到“系统整体资源”的约束，你必须把进程级和系统级调度一并考虑。

6.3 用户代码中如何正确封装并行算法调用

为了不把“并行策略”硬编码在整个工程各处，我会做一个简单的封装层。思路是定义项目内的执行策略变量，允许通过环境变量或编译选项控制实际策略：

// policy.hpp #include <execution> #include <cstdlib> namespace mylib { inline auto& get_policy() { static std::execution::parallel_policy policy = std::execution::par; // 调试时可换成 std::execution::seq 以复现串行结果 return policy; } }

然后业务代码统一调用mylib::parallel_sort(begin, end)这类封装，而封装内部使用std::sort(get_policy(), ...)。这样做的好处很明显：排查问题时，一行代码切换整个工程的并行/串行模式；上线前也可以收集“哪种策略在哪个平台更快”的数据，再针对不同平台设置默认值。虽然标准库本身已经让我们省去很多封装工作，但这种隔离仍然是值得的，尤其当团队有几十个文件都用了并行算法时。

7. 基于实测经验总结的实操建议与选型标准

写到这里，我发现最有价值的部分其实是淘汰那些“伪优化”。很多团队一听到“并行算法”，就以为把sort和transform全部加上par就完工了。根据近年我实际接触和测试的项目来看，反而是在认真做了性能剖析之后，才用并行STL把真正的计算热点加速了3到5倍。这个过程中我积累了几条靠谱的建议，写出来供你参考。

第一，先剖析，后并行。不要凭感觉给所有循环加执行策略。先用性能剖析器找出热点，再针对热点做数据竞争分析。很多算法即使并行化效果也不错，但给一段只占总耗时2%的代码上并行，收益微乎其微，还白白引入了不确定性和调试负担。

第二，优先改造“纯计算、少依赖”的算法块。比如颜色空间转换、像素滤波、数值积分、矩阵元素级运算，这些都是并行STL的黄金场景。如果算法内部存在跨迭代的状态依赖、短路径返回或严格的输出顺序要求，先做重构再并行。

第三，设定你的“并行收益阈值”。建议团队里约定一个基准规则，比如数据量小于5万或单元素处理时间低于1微秒的操作不并行。这个阈值不是标准的、精确的，但能防止无意义并行蔓延到代码库。我习惯在代码注释里写明为什么这段并行值得，这对后续维护者很有帮助。

第四，对一个变量进行多次读写或者对容器进行并发修改时，不要侥幸指望“碰巧不会冲突”。数据竞争在并行STL里是不可容忍的。正规的做法始终是：能只读就只读、能无共享就无共享、必须共享就用std::atomic或者加锁但务必控制在极短临界区，最好让设计本身彻底避免临界区。

再说一个很多人不知道的小坑：不要在一个已经用了并行STL的排序回调里再开并行STL。如果外层std::sort(std::execution::par, ...)的回调里又调用一个并行transform，就可能造成两层递归地把线程池撑满，带来不必要的上下文切换。有一次我的程序就在这种嵌套调用上跑了几个小时不结束，最后发现是任务嵌套直接把线程池的任务队列积压爆了。现在我对嵌套并行会保持高度警惕。

8. 资料与后续扩展方向

8.1 如何利用标准库文档与源码深化理解

并行STL的表面API不难记，但“为什么是这个语义”必须去读标准文档。我推荐读原始标准草案中关于执行策略的章节，重点关注每个策略允许实现做什么、禁止做什么，以及哪些行为属于未定义。像我前面说的“par_unseq允许交错执行仿函数”、“执行策略下异常会导致terminate”，这些都有明确的条款。用编译器源码（例如libstdc++的bits/stl_algo.h或TBB的接口层）来验证理解也很好，你能看到算法实现如何在“块大小”和“任务调度”之间做平衡。看源码不是要你改它，而是让你的心智模型更接近现实。

8.2 进一步阅读：并行模式、国内外会议技术与开源社区

如果你想深入并行算法的更广泛应用，可以关注并行模式（比如map、reduce、scan、stencil）在图形图像、科学计算、大数据预处理中的体现。这些模式和STL算法是一脉相承的，掌握了transform_reduce和inclusive_scan之后再去看GPU或分布式计算框架，你会觉得世界是连续的整体。国内外的技术会议上也经常出现并行算法和C++标准的专题分享，搜一搜就能找到不少高质量资料。开源社区里，TBB本身的项目教程、一些著名开源库的并行实现，都是很好的第二手教材。我自己在这条路线上的体会是：把标准库源码和TBB源码对照着读个两三遍，很多之前靠死记的规则就能自然记住了。

最后，如果一定要我给你一条最浓缩的建议：并行STL是一个强大的工具，但它的力量来自“对数据依赖的正确判断”和“对实测结果的尊重”。不要迷信并行，也不要怕并行；分析清楚自己代码的依赖结构，从最值得并行的计算点下手，设计好无共享的数据访问方式，再借助工具逐一验证正确性和性能。这样得到的优化成果，才是既快又稳、既清晰又可维护的。希望这篇文章能帮你少走一些我走过的弯路。