pthread_setaffinity_np常不生效的最常见原因是cpu_set_t未初始化：栈上变量内容随机，高位可能置位导致掩码非法，调度器拒绝请求并返回EINVAL；必须先CPU_ZERO清空位图，再CPU_SET目标核号，且core_id从0开始、不超系统逻辑CPU数。
必须在新线程函数内部调用 pthread_setaffinity_np，不能靠主线程“远程”设置；传入未初始化的 cpu_set_t 会导致静默失败或 EINVAL 错误。
为什么 pthread_setaffinity_np 常常不生效？
最常见原因是 cpu_set_t 没初始化：直接定义 cpu_set_t set; 后就调用 CPU_SET，但栈上变量内容随机，高位可能置位，导致掩码非法。调度器会拒绝该请求，返回 EINVAL，但很多代码只检查返回值是否为 0，忽略 errno。
- 必须先调用
CPU_ZERO(&set)清空整个位图 -
CPU_SET(core_id, &set)中的core_id从 0 开始，且不能超过系统实际逻辑 CPU 数（可用sysconf(_SC_NPROCESSORS_ONLN)获取） - 若目标核已离线（如通过
/sys/devices/system/cpu/cpu1/online关闭），调用返回ENODEV - 传给
pthread_setaffinity_np的第二个参数是sizeof(set)，不是sizeof(cpu_set_t)—— 前者是运行时实际大小，后者在不同内核版本下可能不一致
std::thread 怎么安全绑定到指定核心？
不能在线程构造后立刻对 t.native_handle() 调用 pthread_setaffinity_np：此时线程可能尚未进入调度队列，pthread_setaffinity_np 可能返回 ESRCH（No such process）。
- 正确做法是在线程函数入口第一行完成绑定：
pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset) - 如果必须由主线程控制（如统一管理绑核策略），需在线程函数中先设置一个原子标志（如
std::atomic<bool> ready{false}</bool>），等主线程看到ready == true后再调用绑定——但这增加同步开销，通常没必要 - 不要试图用
std::this_thread::sleep_for“等待线程启动”，不可靠且破坏确定性
如何验证绑定是否真正生效？
仅看代码返回值为 0 不代表成功：调度器可能接受请求但后续因负载、中断等原因仍发生迁移。真实有效性必须运行时验证。
立即学习“C++免费学习笔记（深入）”；
- 在绑定后立即调用
sched_getcpu()，返回值应与预期core_id一致 - 外部用
taskset -p <pid></pid>查看进程级掩码（注意：它显示的是主线程的亲和性，子线程需单独查） - 查具体线程：先用
ps -T -p <pid></pid>获取TID，再执行taskset -p <tid></tid> - 长期运行中建议定期采样
sched_getcpu()，防止因fork或信号处理导致意外迁移
跨核心迁移的代价远比想象中高：一次 L1 缓存失效可能带来 4–5 倍延迟，NUMA 远程访存更是轻松翻倍。但绑核本身不是银弹——若把计算线程和 IO 线程绑在同一物理核的超线程逻辑对上，反而加剧争抢。真正的难点从来不是“怎么写那几行代码”，而是理解你程序的数据流、内存分布和硬件拓扑之间的耦合关系。
