linux下用pthread_setaffinity_np绑定线程到指定cpu核心需先cpu_zero清空cpu_set_t再cpu_set添加核号，核号从0开始；windows中setthreadaffinitymask是硬约束而setthreadidealprocessor仅为建议。
Linux下用pthread_setaffinity_np绑定线程到指定CPU核心
Linux原生支持线程级CPU亲和性控制，关键函数是pthread_setaffinity_np。它不是POSIX标准函数（带_np后缀），但glibc广泛支持，生产环境可用。
常见错误是传入空或未初始化的cpu_set_t——必须先调用CPU_ZERO清空，再用CPU_SET添加目标核号。核号从0开始，比如双核机器只有0和1。
- 示例：绑到CPU 2（即第三个物理核）：
cpu_set_t cpuset;<br>CPU_ZERO(&cpuset);<br>CPU_SET(2, &cpuset);<br>pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
- 检查是否生效：运行后用
taskset -p <em><pid></pid></em>查看；或在代码里调用pthread_getaffinity_np验证 - 注意
sizeof(cpuset)不能写成sizeof(cpu_set_t)——前者是实际位图大小，后者可能不匹配系统CPU数量
Windows下用SetThreadIdealProcessor和SetThreadAffinityMask的区别
Windows没有直接等价于pthread_setaffinity_np的API，两个常用函数作用不同，容易混淆：
-
SetThreadIdealProcessor只是“建议”调度器优先在某核运行，不强制；调度器可忽略 -
SetThreadAffinityMask才是硬约束，指定线程只能在掩码对应的核心上运行 - 掩码是DWORD或DWORD64：bit 0 = CPU 0，bit 1 = CPU 1……例如想绑到CPU 3，掩码值为
1ULL （即8） - 调用前需用
GetCurrentThread()获取句柄，且返回值必须检查——失败时返回0，不是-1
跨平台封装时为什么不能只靠#ifdef __linux__
看似简单加条件编译就行，但实际有隐藏坑：
- macOS完全不支持线程亲和性，
pthread_setaffinity_np根本不存在，链接会失败 - 某些嵌入式Linux（如musl libc）也不提供
_np系列函数 - Windows的
SetThreadAffinityMask要求进程本身有SE_INCREASE_QUOTA_NAME权限，否则静默失败 - 建议做法：运行时检测函数指针是否非NULL（Linux用
dlsym，Windows用GetProcAddress），失败则记录warn日志，不abort
设置亲和性后性能反而下降的常见原因
绑核不是万能优化，很多场景适得其反：
- 绑到被其他高负载进程占用的CPU上，导致争抢而非独占
- 绑到超线程的逻辑核（如CPU 0和CPU 4共享物理核），没真正隔离缓存和执行单元
- 线程频繁阻塞（如等待IO或锁），绑核后唤醒时仍要迁移到其它核，反而增加开销
- NUMA架构下绑到远端内存节点对应的CPU，访存延迟飙升——此时应同时绑定内存节点（
numactl或mbind）
真要压测效果，得用perf stat -e cycles,instructions,cache-misses对比绑核前后的硬件事件计数，而不是只看wall time。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
