吞吐量瓶颈通常不在线程数量，而在内存访问模式、锁竞争和任务划分不合理；需显式指定std::launch::async、优化内存布局、合理选用原子操作，并按i/o或cpu密集型差异配置线程数。
直接结论：吞吐量瓶颈通常不在“开了多少线程”，而在内存访问模式、锁竞争和任务划分不合理——这三个点调不对，开 64 个线程可能比 4 个还慢。
std::async + vector 分块并行的常见陷阱
很多人照搬 std::async 分块处理 std::vector 的例子，但实际中容易踩坑：
- 默认
std::async启动策略是std::launch::async | std::launch::deferred，某些编译器（如旧版 GCC）会退化为延迟执行，导致“看似并发、实则串行” - 分块大小硬写成
n / num_threads，当n % num_threads != 0时最后一块被漏掉或越界（示例代码里用(t == num_threads -1) ? n : start + chunk_size是对的，但手写易错） - 每个
std::future持有完整闭包，若捕获了大对象（如整个std::vector而非 const 引用），会触发隐式拷贝，反而拖慢速度
建议显式指定 std::launch::async，并用 const std::vector<double>&</double> 捕获，避免值传递。
内存布局不连续导致缓存失效
多线程遍历结构体数组（AoS）时，如果字段排列混乱，CPU 预取失败、缓存行浪费，吞吐量立刻腰斩：
- 错误示例：
struct Record { int id; char flag; double value; std::string tag; }——std::string指针分散，char flag强制 4 字节对齐，中间填充 3 字节，空间局部性差 - 正确做法：把频繁访问字段前置、同类型聚合；大对象（如
std::string）抽离成单独索引数组；优先用std::vector<double></double>存数值，而非std::vector<record></record> - 关键验证：用
perf stat -e cache-misses,cache-references看缓存未命中率，>5% 就值得重构内存布局
锁粒度与原子操作选型失当
共享计数器、结果聚合、日志写入等场景，锁用错一个字，吞吐就掉一半：
-
std::mutex保护单个整数递增？太重——改用std::atomic_int counter{0}，counter.fetch_add(1)延迟仅 10–50 ns，而 mutex 锁平均 100–1000 ns - 多个线程往同一个
std::vectorpush_back？别用锁，改用线程本地缓冲 + 最后合并，或预分配 size 后用下标写入（result[i] = ...） - 需要条件通知？
std::condition_variable必须和std::unique_lock配合，且wait()内部已含 unlock/relock，别在外面重复 lock
特别注意：std::atomic 对复合操作（如“读-改-写”非幂等逻辑）不安全，这时仍需锁或 compare_exchange_weak 循环。
线程数 ≠ 核心数，I/O 和 CPU 密集型要分开调
吞吐量卡在 I/O（如 CSV 解析、网络收包）还是计算（如矩阵乘、统计聚合），线程配置完全相反：
- CPU 密集型任务：线程数 ≈
std::thread::hardware_concurrency()，再多只会增加上下文切换开销 - I/O 密集型任务（如 mmap+解析 CSV）：可设为 2–3 倍核心数，但必须配合异步 I/O 或双缓冲（如
fast-cpp-csv-parser的#define CSV_IO_THREAD_POOL） - 混合型任务：拆成 pipeline 阶段——I/O 线程只负责读/解码，CPU 线程池只做计算，用无锁队列（如
moodycamel::ConcurrentQueue）传递数据块
最容易被忽略的是：线程创建本身有开销，短生命周期任务（
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
