pthread_setaffinity_np用于Linux下绑定线程到指定CPU核心，需正确初始化cpu_set_t、检查返回值、在std::thread构造后立即调用，并注意超线程与NUMA影响。
pthread_setaffinity_np 绑定线程到 CPU 核心（Linux）
Linux 下 C++ 线程绑定核心，本质是调用 pthread_setaffinity_np 设置线程的 CPU 亲和性掩码。它不关心你用的是 std::thread 还是原生 pthread_t，只要拿到线程句柄就能操作。
常见错误是直接对 std::thread::native_handle() 返回值调用该函数却没检查类型——在 Linux 上它确实是 pthread_t，但这是平台实现细节，不能跨平台假设；更隐蔽的问题是传入空或非法的 cpu_set_t* 导致段错误。
- 必须先用
CPU_ZERO(&set)清空掩码，再用CPU_SET(cpu_id, &set)显式设置目标核心（比如绑到 0 号核就只设CPU_SET(0, &set)） - 调用后务必检查返回值：
if (pthread_setaffinity_np(thread.native_handle(), sizeof(set), &set) != 0)，失败通常意味着cpu_id超出系统实际核心数（sysconf(_SC_NPROCESSORS_ONLN)可查） - 如果线程已启动，需在
thread.join()前调用，否则可能被调度器重新打散
std::thread 构造后立即绑定（避免竞态）
很多同学在线程启动后“稍等一下”再绑定，结果发现没生效——因为线程可能已在其他核上跑完任务。绑定动作必须紧挨着 std::thread 构造之后、任何用户逻辑执行之前。
典型场景：高性能计算中初始化阶段就固定工作线程到物理核，防止上下文切换抖动。这时别依赖 sleep 或计时器“等线程跑起来”，而是构造完立刻操作。
立即学习“C++免费学习笔记（深入）”；
- 示例：
std::thread t([]{ /* work */ });<br>cpu_set_t set;<br>CPU_ZERO(&set);<br>CPU_SET(2, &set);<br>pthread_setaffinity_np(t.native_handle(), sizeof(set), &set);<br>t.join(); - 若用类封装线程，把绑定逻辑塞进构造函数末尾，比暴露
set_affinity()方法更可靠 - 注意：主线程默认可跑在任意核，若你也想固定它，对
pthread_self()同样调用pthread_setaffinity_np
Windows 上用 SetThreadAffinityMask（非跨平台）
Windows 没有 pthread_setaffinity_np，对应 API 是 SetThreadAffinityMask，参数是线程句柄和位掩码（bitmask），比如绑到第 3 号核要传 1ULL << 3，不是数字 3。
容易踩的坑是混淆 GetCurrentThread() 和真实句柄——它返回伪句柄，不能直接传给 SetThreadAffinityMask；正确做法是用 OpenThread(THREAD_ALL_ACCESS, FALSE, thread_id) 获取可操作句柄，或者用 std::thread 的 native_handle()（Windows 上是 HANDLE 类型）。
-
SetThreadAffinityMask返回旧掩码，若返回 0 表示失败（比如线程已退出或权限不足） - Windows 核心编号从 0 开始，但掩码是按位索引，
1 << 0是第 0 核，1 << 7是第 7 核，别写成7 - 若程序需同时支持 Linux/Windows，建议封装一层
bind_to_cpu(int cpu_id)，内部用#ifdef _WIN32分支
绑核后反而变慢？小心超线程和 NUMA
单纯绑定到某个 cpu_id 不等于获得独占资源。现代 CPU 有超线程（HT），两个逻辑核共享一套 ALU，绑到同一物理核的两个超线程上可能互相干扰；NUMA 架构下，绑到远离内存控制器的核会显著增加访存延迟。
这时候 cpu_id 的选择就关键了——别硬编码 0、1、2……而应根据 lscpu 或 /proc/cpuinfo 查清物理核与逻辑核映射关系。例如 Intel 8 核 16 线程机器，0 和 8 是同一物理核的两个超线程，应避开同时绑定。
- 用
taskset -c 0-3 ./a.out可临时验证绑核效果，配合perf top观察是否真在目标核运行 - 若用容器或虚拟机，宿主机的 CPU 隔离策略（如
cgroups v2的cpuset）可能覆盖进程级绑定，得一起配 - 调试时别忘了：gdb 默认会把被调试线程迁移到 gdb 所在核，看到的
top输出可能失真
事情说清了就结束。真正难的不是调哪个函数，而是搞懂你的 CPU 拓扑、确认绑核后内存访问路径没绕远、以及验证调度器确实没偷偷把你踢走。
