前言线程亲和性thread affinity也译作 CPU 亲和性指的是把一个线程限制在某个或某组 CPU 核心上运行。它常出现在低延迟、高频交易、音视频实时处理、数据库内核这类对缓存命中率和调度抖动敏感的场景里。围绕它的说法很多最常见的误解有两个一是以为「绑核一定更快」二是以为 C 标准库提供了绑定接口。事实是C 标准截至 C23没有定义任何线程亲和性 API。std::thread、std::jthread只描述线程的创建、加入与协作取消不涉及线程跑在哪个核上。要做绑核只能通过native_handle()拿到平台句柄再调用操作系统的接口Linux 上是pthread_setaffinity_npWindows 上是SetThreadAffinityMask一类的函数。这意味着相关代码天然不可移植必须明确标注平台。本文先讲亲和性在什么情况下有价值、什么情况下反而有害再分别给出 Linux 与 Windows 的实现方式最后讲如何验证绑定是否生效以及怎样用测量而不是感觉做判断。文中不给出任何「绑核后提升多少」的数字因为这类结果高度依赖硬件拓扑、负载形态和调度器版本必须由读者在自己的机器上测。一、亲和性解决什么问题又不解决什么现代 CPU 的每个核心有自己的 L1/L2 缓存多个核心共享 L3多路服务器上还有 NUMA 节点跨节点访问内存的延迟明显高于本地节点。线程如果在核间频繁迁移原先装在某个核私有缓存里的数据就用不上了需要重新从更远的层级取同时迁移本身也带来调度开销。把线程固定在一个核上可以稳定它的缓存工作集减少这类抖动。但绑定是有代价的。第一被绑定的线程如果进入阻塞等待 I/O、锁、条件变量它占住的那个核不会让给别的可运行线程系统整体吞吐可能下降。第二绑核把调度决策从内核手里拿走了一部分如果绑定方案与真实负载不匹配会出现「一个核忙死、其他核闲着」的局面。第三超线程SMT下两个逻辑核共享执行单元把它们当成两个独立物理核来分配任务收益可能与预期相反。因此适用场景大致是场景是否适合绑核原因实时音频/视频回调线程适合需要稳定的唤醒延迟与缓存局部性高频交易的关键路径适合且常配合隔离核抖动比平均吞吐更重要计算密集且线程数等于物理核数可尝试减少迁移但需防止负载不均I/O 密集、频繁阻塞通常不适合阻塞时浪费核心线程数远大于核数不适合调度器需要额外自由度短生命周期任务不适合绑定开销与收益不成比例真正决定要不要绑的是「抖动」还是「吞吐」更重要。如果程序对尾延迟敏感绑核往往值得试如果只关心单位时间完成多少任务默认调度器通常已经做得不错。二、C 标准库能提供什么标准库提供的是线程对象和硬件并发数不提供亲和性// 适用于 C17#include thread#include iostreamint main() {unsigned n std::thread::hardware_concurrency();std::cout hardware_concurrency n \n;std::thread t([] { /* ... */ });t.join();return 0;}hardware_concurrency()返回的是「实现估计的并发线程数」标准明确说这个值只是提示可能为 0也不区分物理核与超线程逻辑核。把它当作可用的物理核数是常见的错误。要接触平台能力用native_handle()Linux 上返回pthread_tWindows 上返回HANDLE。这个函数的类型是实现定义的所以调用处必须与平台绑定。// 适用于 C17仅示意类型差异不可同时编译std::thread t(worker);auto native t.native_handle(); // Linux: pthread_tWindows: HANDLE三、Linux 下的实现Linux 的 pthread 提供了两个非可移植名称里的_np即 non-portable接口int pthread_setaffinity_np(pthread_t thread, size_t cpusetsize, const cpu_set_t *cpuset);int pthread_getaffinity_np(pthread_t thread, size_t cpusetsize, cpu_set_t *cpuset);cpu_set_t是一个位图类型用CPU_ZERO、CPU_SET、CPU_ISSET、CPU_COUNT这组宏操作。使用这些宏通常需要定义_GNU_SOURCE在包含头文件之前链接时加-pthread。sched_getaffinity/sched_setaffinity是另一组等价接口作用于线程 IDLinux 上线程即轻量级进程gettid()可取到。一个完整的绑定封装// 适用于 C17Linux / glibc 平台#define _GNU_SOURCE#include pthread.h#include sched.h#include cstdio#include thread#include vector// 返回 false 表示系统调用失败原因可用 errno 查看bool pin_thread_to_cpu(std::thread t, int cpu_index) {cpu_set_t set;CPU_ZERO(set);CPU_SET(cpu_index, set);int rc pthread_setaffinity_np(t.native_handle(), sizeof(set), set);return rc 0;}int main() {unsigned hw std::thread::hardware_concurrency();if (hw 0) {std::puts(cannot detect cpu count);return 1;}std::vectorstd::thread pool;for (unsigned i 0; i hw; i) {pool.emplace_back([] {// 工作负载放在这里});}for (unsigned i 0; i pool.size(); i) {if (!pin_thread_to_cpu(pool[i], static_castint(i))) {std::perror(pthread_setaffinity_np);}}for (auto th : pool) {th.join();}return 0;}这里有一个关键的时序问题pthread_setaffinity_np作用在已经存在的线程上而线程创建后立刻就开始执行了。上面示例把绑定放在创建之后线程可能在绑定生效前已经跑了一小段。对严格的实时路径常见做法是让工作线程在入口处等待一个条件变量或原子标志主线程完成绑定后再放行// 适用于 C17Linux 平台#include atomic#include condition_variable#include mutexstd::mutex g_mu;std::condition_variable g_cv;bool g_go false;void worker_entry() {{std::unique_lockstd::mutex lk(g_mu);g_cv.wait(lk, [] { return g_go; });}// 此时绑定已经生效开始实际工作}主线程在pin_thread_to_cpu返回后持锁把g_go置为true并notify_all()。注意谓词等待必须配合互斥量使用否则会有虚假唤醒与数据竞争问题g_go的读写都在锁内完成不需要额外声明为std::atomic但若挪到锁外就必须用原子类型。另外用CPU_SET(i, ...)时i必须落在系统允许的 CPU 集合内。容器环境里可用的 CPU 往往是被 cgroup 限制过的子集直接按0..hardware_concurrency()-1编号可能与实际可调度集合不一致。更稳妥的做法是先sched_getaffinity(0, ...)读出当前线程允许的集合再在这个集合里选核。四、Windows 下的实现Windows 用线程句柄和位掩码表示亲和性// 适用于 C17Windows 平台需包含 windows.h#include windows.h#include thread#include cstdiobool pin_thread_to_cpu(std::thread t, int cpu_index) {if (cpu_index 0 || cpu_index 64) {return false; // 单个 DWORD_PTR 掩码在 64 位下最多覆盖 64 个逻辑处理器}DWORD_PTR mask DWORD_PTR(1) cpu_index;DWORD_PTR prev SetThreadAffinityMask(static_castHANDLE(t.native_handle()), mask);return prev ! 0;}SetThreadAffinityMask返回之前的掩码失败返回 0应配合GetLastError()排查。逻辑处理器超过 64 个时需要用处理器组processor group相关 API单个DWORD_PTR掩码不够用这一点在大型服务器上必须注意。Windows 没有与pthread_setaffinity_np完全对等的「按线程 ID 设置」的简单接口通常是在目标线程内部调用SetThreadAffinityMask(GetCurrentThread(), mask)或者先OpenThread拿到句柄。前者更简单也避开了「线程已开跑」的时序问题。五、如何确认绑定生效不要凭感觉判断。Linux 上有几种直接的观察手段taskset -pc pid查看进程的亲和性掩码/proc/pid/status里的Cpus_allowed_list字段/proc/pid/task/tid/status查看单个线程perf stat -e context-switches,cpu-migrations观察迁移次数是否下降。Windows 上可在任务管理器的「详细信息 → 设置相关性」中查看或用GetThreadGroupAffinity读取。性能验证要用std::chrono::steady_clock或perf、Google Benchmark 这类工具并且控制变量同样的负载、同样的编译选项、多次运行取分布而不是只看一次。迁移次数、缓存未命中率、尾延迟分位数往往比平均耗时更能说明问题。测量噪声来源包括频率调节、其他进程干扰、首次运行的页错误至少要做预热并重复多轮。常见坑点❌ 认为std::thread有set_affinity()成员。✅ 标准库没有该接口通过native_handle()调用平台 API。❌ 在 Linux 上按0..N-1硬编码 CPU 编号容器里越界失败。✅ 先用sched_getaffinity读取允许集合再从中选择。❌ 创建线程后立即绑定就认为线程从第一条指令起就在目标核上。✅ 用条件变量或原子标志让工作线程等绑定完成后再开始。❌ 把 I/O 密集线程也绑死在一个核上。✅ 只在抖动敏感的短关键路径上绑定阻塞型线程交给调度器。❌ 用hardware_concurrency()当作物理核数来决定绑核数量。✅ 它可能包含超线程逻辑核且标准只把它当提示需结合拓扑信息判断。❌ 绑核后不做任何测量就宣布优化成功。✅ 用迁移次数、缓存指标、尾延迟分位数做前后对比并说明测量条件。❌ 在跨平台代码里直接写pthread_setaffinity_np。✅ 用编译期宏隔离平台实现并为不支持的平台提供空实现。❌ 忘记-pthread或_GNU_SOURCE编译或链接失败后归咎于「系统不支持」。✅ Linux 下加-pthread并在包含头文件前定义_GNU_SOURCE。总结维度结论标准支持C17/20/23 均无亲和性 API需平台接口Linux 入口pthread_setaffinity_np/sched_setaffinityWindows 入口SetThreadAffinityMask超过 64 逻辑核需处理器组主要收益减少迁移、稳定缓存工作集、降低尾延迟抖动主要风险阻塞时浪费核心、负载不均、与调度器策略冲突生效时机绑定需在目标线程开始关键工作之前完成验证手段taskset、/proc状态、perf、分位数统计线程亲和性是一把针对「确定性」而非「吞吐」的刀。它不能凭空提升算力只是把线程放在你希望它在的地方是否值得取决于你的瓶颈是缓存与调度抖动还是纯粹的并行度不足。先测量、再绑定、绑完再测量这个顺序不能颠倒。