Linux下用pthread_setaffinity_np绑定线程到CPU核心是最直接方式，需初始化cpu_set_t、检查返回值；std::thread须在线程函数内调用绑定；Windows对应SetThreadAffinityMask，需用GetCurrentThread()获取伪句柄；绑定非万能，需注意NUMA、抢占、虚拟化等限制。
Linux 下用 pthread_setaffinity_np 绑定线程到 CPU 核心
这是最直接、最常用的方式，但要注意它只在 Linux（glibc）和部分 Unix 系统上可用，Windows 不支持。调用前必须确保线程已创建且正在运行（或至少已启动），否则行为未定义。
常见错误是传入空的 cpu_set_t 或忘记初始化——结果线程可能被调度器随意迁移，甚至静默失败。
- 先用
CPU_ZERO(&set)清空集合，再用CPU_SET(core_id, &set)设置目标核心（core_id从 0 开始） - 调用
pthread_setaffinity_np(thread, sizeof(set), &set)，检查返回值是否为 0；非零值表示失败（如EINVAL表示 core_id 超出系统实际核心数） - 若线程是用
std::thread创建的，需先用.native_handle()获取底层pthread_t
std::thread 启动后无法直接设置亲和性？
可以，但必须在新线程内部主动调用绑定逻辑，不能靠主线程“远程操作”。因为 std::thread 构造函数不提供亲和性参数，且 native_handle() 返回的 pthread_t 在线程未启动前无效。
典型误用：在 std::thread t{func} 后立刻对 t.native_handle() 调用 pthread_setaffinity_np —— 此时线程可能还没真正进入调度队列，pthread_setaffinity_np 可能返回 ESRCH（No such process）。
立即学习“C++免费学习笔记（深入）”；
- 安全做法是在
func入口第一行就做绑定：先cpu_set_t set，再CPU_ZERO/CPU_SET，最后pthread_setaffinity_np(pthread_self(), ...) - 如果必须由主线程控制，可用条件变量或原子标志等待子线程进入“就绪态”后再绑定（但增加复杂度，通常没必要）
Windows 上怎么等效实现？
Windows 没有 pthread_setaffinity_np，对应的是 SetThreadAffinityMask，且操作对象是 HANDLE，不是线程 ID。
容易踩的坑是把 std::thread::id 当作可直接使用的句柄——它只是个标识符，不能传给 Win32 API。必须用 OpenThread 获取句柄，而该函数要求线程已运行且有 THREAD_QUERY_INFORMATION 权限。
- 推荐在线程函数内调用
GetCurrentThread()（返回伪句柄，无需权限），再传给SetThreadAffinityMask - 掩码是位图：绑定到核心 0 →
1ULL << 0，核心 3 →1ULL << 3；多核用按位或，如(1ULL << 0) | (1ULL << 1) - 注意：Win10 20H1+ 支持
SetThreadIdealProcessorEx，可指定更细粒度的处理器组，但兼容性更低
绑定后性能反而下降？几个关键干扰点
亲和性不是银弹。强制绑定可能破坏 NUMA 局部性、缓存预热节奏，或导致核心过载。尤其当线程频繁阻塞（如 IO、锁等待）时，绑定反而降低调度灵活性。
最容易被忽略的是：绑定本身不保证独占核心。其他线程/进程仍可抢占，除非你配合 taskset 启动整个进程，或用 cgroups 限制 CPU 配额。
- 用
cat /proc/<pid>/status | grep Cpus_allowed_list确认进程级允许范围，避免线程绑定到被父进程屏蔽的核心 - 高频率绑定/解绑（如每毫秒调一次）会显著增加系统调用开销，应避免在热循环中反复调用
pthread_setaffinity_np - 某些虚拟化环境（如 WSL2、容器）下，CPU 核心编号与宿主机映射关系不稳定，
lscpu显示的 “CPU(s)” 数量 ≠ 实际可用物理核心数
