关键在任务划分、线程绑定与数据局部性协同；否则因缓存失效、锁竞争或NUMA远程访问导致CPU使用率低下，需用亲和性绑定、避免伪共享、合理分段加锁并压测调优。
直接结论：光创建多个 std::thread 不等于真正用满多核；关键在任务划分、线程绑定、数据局部性三者协同，否则可能卡在锁竞争、缓存失效或 NUMA 远程内存访问上。
为什么 std::thread 创建后 CPU 使用率还是上不去？
常见现象是开了 16 个线程，top 看 CPU 总使用率却只有 40%～60%，且 perf stat 显示大量 cache-misses 或 LLC-load-misses。这不是线程没跑起来，而是它们被调度器“乱扔”到不同物理核心甚至不同 NUMA 节点上，导致：
- 线程频繁迁移，L1/L2 缓存反复失效
- 同一组共享数据被多个线程在不同 socket 上争抢，触发跨节点内存访问（延迟翻倍以上）
- 默认调度策略偏向“公平”，而非“局部性”，对计算密集型任务反而有害
如何让每个线程稳定运行在指定物理核心上？
C++ 标准库不提供亲和性控制，必须调用系统 API。Linux 下用 pthread_setaffinity_np，Windows 下用 SetThreadAffinityMask。实操建议：
- 在
std::thread启动后、执行任务前立即设置亲和性，避免被调度器抢先迁移 - 用
hwloc库（推荐）或lscpu输出手动映射逻辑核到物理核，避开超线程伪核（如只用 0,2,4,...） - 示例片段（Linux）：
void bind_to_core(int core_id) { cpu_set_t cpuset; CPU_ZERO(&cpuset); CPU_SET(core_id, &cpuset); pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset); } // 在线程函数开头调用 void worker_task() { bind_to_core(3); // 绑定到物理核 3 // ... 实际计算 }
std::thread + 共享数据时最容易踩的性能坑
不是所有共享都该加 std::mutex —— 错误的同步方式会把并行变成串行：
立即学习“C++免费学习笔记（深入）”；
- 用
std::atomic<int>替代锁保护单个计数器，避免锁开销（但注意atomic不保证指令重排，必要时加memory_order） - 避免“大锁”：不要用一个
std::mutex保护整个容器，改用分段锁（如哈希桶粒度）或无锁结构（boost::lockfree::queue） - 写时复制（Copy-on-Write）比读写锁更轻量，适合读多写少场景；但 C++ 标准容器不支持，需自行封装或用
folly::AtomicUnorderedMap - 警惕 false sharing：不同线程修改同一 cache line（64 字节）里的不同变量，会导致该行在核心间反复无效化；用
alignas(64)强制变量独占 cache line
线程数设多少才合理？
别盲目等于 std::thread::hardware_concurrency() 返回值：
- CPU 密集型任务：通常设为物理核心数（非逻辑核），例如 32 核服务器设 32 线程；超线程（HT）仅在混合负载（如部分线程等 I/O）时才有收益
- IO 密集型任务：可略高于物理核数（如 ×1.5），但需配合异步 I/O（
io_uring）或线程池避免阻塞扩散 - 实际应压测验证：从物理核数开始，逐步增减，用
perf record -e cycles,instructions,cache-references,cache-misses观察 IPC（Instructions Per Cycle）是否下降
真正榨干多核的关键，往往不在怎么开线程，而在怎么让每个线程“待在它该待的地方”，并“只碰它该碰的数据”。缓存行对齐、NUMA 感知分配、亲和性绑定——这些细节不写进代码里，再多的 std::thread 也只在原地打转。
