17370845950

根本原因是任务粒度太小或数据局部性差，导致调度开销超过计算收益；需确保单次迭代含数百周期操作、避免频繁内存分配与锁竞争，并使用affinity_partitioner提升NUMA性能。

为什么直接调用 tbb::parallel_for 有时不加速反而变慢

根本原因不是并行逻辑写错了，而是任务粒度太小或数据局部性差。TBB 的任务调度器会把循环体拆成子任务扔进全局任务队列，但如果每次迭代只做几条加法、访问分散内存，调度开销（任务创建、窃取、同步）就压倒了计算收益。

• 确认是否真有足够计算量：单次迭代至少应含数百个周期级操作，比如向量点积、矩阵块乘、哈希计算
• 避免在 parallel_for 循环体内频繁 new/delete 或锁竞争，这会让线程阻塞在内存分配器或互斥量上
• 用 tbb::affinity_partitioner 替代默认分区器，尤其在 NUMA 架构下能减少跨节点内存访问延迟

auto ap = tbb::affinity_partitioner{};
tbb::parallel_for(tbb::blocked_range(0, n), [&](const tbb::blocked_range& r) {
    for (size_t i = r.begin(); i != r.end(); ++i) {
        // 确保此处有实际工作，而非空循环或简单赋值
        result[i] = heavy_computation(data[i]);
    }
}, ap);

如何让自定义任务真正被 TBB 调度器管理而不是“假并行”

很多人用 std::thread 手动拉起线程再调 tbb::task_group，结果任务仍在主线程执行——因为没显式 spawn。TBB 的任务必须通过 task_group::run() 或 task_group::wait() 触发调度，且不能在栈上构造任务对象。

• 任务类必须继承 tbb::task，重载 execute()，返回 tbb::task*（通常为 nullptr）
• 禁止在局部作用域 new 任务后直接调 spawn()：任务可能在线程退出前就被执行完，导致悬垂指针
• 更安全的做法是用 tbb::task_group + lambda，它自动管理生命周期

tbb::task_group tg;
tg.run([]{
    process_chunk(left_part);
});
tg.run([]{
    process_chunk(right_part);
});
tg.wait(); // 阻塞直到所有 run 提交的任务完成

tbb::concurrent_hash_map 在高并发写入时为何卡死或崩溃

常见误用是忽略其线程安全边界：它只保证单个 key 的插入/查找/删除是线程安全的，但对跨 key 的复合操作（如“检查不存在则插入”）仍需手动加锁。另外，迭代器遍历时若其他线程正在修改，行为未定义。

• 避免使用 find() + insert() 组合，改用 insert_or_assign() 或 try_emplace()
• 不要保存 concurrent_hash_map::iterator 跨越多个调度点，它不保证长期有效
• 如果需要批量初始化，先用普通 std::unordered_map 构建，再 move 构造 tbb::concurrent_hash_map

链接 TBB 时出现 undefined reference 到 tbb::task_group_context::init() 怎么办

这是典型的链接顺序和运行时库不匹配问题。TBB 分动态/静态、debug/release、C++11/17 多个 ABI 变体，libtbb.so 和 libtbb_debug.so 不能混链，且必须在链接命令末尾指定。

• 用 pkg-config --libs tbb 获取正确链接参数，别手写 -ltbb
• 确保编译选项与 TBB 构建时一致：比如 TBB 是用 -std=c++17 编的，你的代码也得用相同标准
• Linux 下若用 -ltbb 仍报错，尝试加 -ltbbmalloc（TBB 内存分配器依赖）

最易被忽略的一点：TBB 任务调度器需显式初始化。虽然多数情况会惰性初始化，但在嵌入式或特殊加载环境下，应在程序启动时调一次 tbb::task_scheduler_init（注意 C++17 后已弃用，改用 tbb::global_control）。