根本原因在于线程与cpu核心未正确绑定。需在子线程函数首行调用pthread_setaffinity_np，传入正确的sizeof(cpu_set_t)，并确保目标核心未被抢占；numa架构下还需线程与内存同节点，且每个线程须显式设置亲和性。
线程跑不满核、性能忽高忽低、负载不均——根本不是代码写得烂，而是线程和CPU核心没对上号。默认调度器会把线程甩来甩去，缓存反复失效，NUMA跨节点访问拖慢几十倍，你写的多线程程序其实在“自废武功”。
pthread_setaffinity_np 绑核后没效果？检查这三件事
很多人调了 pthread_setaffinity_np 却发现 top 里 CPU 使用率还是毛毛雨，问题往往不在函数本身：
- 没在子线程启动后立即调用：主线程绑了没用，必须在
std::thread构造的函数体第一行就执行绑定，否则线程可能已在其他核上跑了几十毫秒，缓存早凉了 - 传错
sizeof(cpu_set_t)：Linux 下这个值是固定常量（通常是 128），不是sizeof(cpuset)；写错会导致系统忽略设置，返回成功但实际无效 - 目标核心被系统或其它进程抢占：比如 systemd 启动时占满 core 0–3，你绑到 core 2，结果它一直在处理中断或 cgroup 调度任务，线程根本抢不到时间片
NUMA 架构下线程和内存必须同节点
在 32 核双路服务器上，只绑核不配内存，性能照样打五折。因为线程在 Socket 0 上运行，却从 Socket 1 的内存读数据，延迟翻倍，带宽腰斩。
- 用
numactl --hardware确认 NUMA 节点布局，看清哪些 core 属于哪个 node - 线程创建前先调
numa_set_preferred(node_id)或直接用numa_alloc_onnode()分配工作内存 - 避免混用：不要让一个线程既访问 node 0 的堆内存，又操作 node 1 的 mmap 区域，这种交叉访问没法优化
std::thread 默认不继承亲和性，每次都要重设
std::thread 构造时不会复制父线程的 CPU 亲和掩码，哪怕你在主线程绑了 core 7，起的新线程依然可能落在 core 0 上随机飘。
- 别依赖主线程设置：每个工作线程的入口函数开头必须显式调
pthread_setaffinity_np(pthread_self(), ...) - 别用
sched_setaffinity(0, ...)：它作用于当前线程 ID，而std::thread内部实现可能复用线程 ID 或切换上下文，行为不可靠 - 验证是否生效：用
taskset -p <pid></pid>查看进程整体掩码，再用ps -T -o pid,tid,psr -p <pid></pid>看每个 LWP（轻量级进程）实际跑在哪个 CPU（psr列）
最常被跳过的一步是验证——你以为绑成功了，其实 CPU_SET(3, &cpuset) 后忘了检查 pthread_setaffinity_np 返回值，而错误码 EINVAL 往往意味着 core ID 超出当前系统可用范围（比如你写了 64，但机器只有 32 核），这种细节一漏，所有优化都白做。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
