Linux下C++无法用标准库实现CPU亲和性，必须调用POSIX扩展pthread_setaffinity_np或系统调用sched_setaffinity；前者接收pthread_t（可用std::thread::native_handle()获取），后者作用于内核线程ID，均需先CPU_ZERO清空掩码、再CPU_SET置位目标核（编号从0开始），并检查返回值与errno，绑定后须用sched_getaffinity或taskset验证生效。
Linux下用sched_setaffinity绑定线程到指定CPU核心
直接结论：C++在Linux中无法靠标准库实现CPU亲和性，必须调用POSIX线程扩展+系统调用sched_setaffinity。它作用于内核线程（即pthread_t对应的LWP），不是C++ std::thread对象本身。
实操要点：
-
std::thread::native_handle()返回的是pthread_t，可传给pthread_setaffinity_np（推荐，更便携） - 若需更底层控制（比如绑定当前线程），用
sched_setaffinity(0, ...)，第一个参数0表示当前线程 - CPU掩码必须用
cpu_set_t类型，且每次使用前必须用CPU_ZERO(&set)清零，否则残留位会导致意外绑定 - 核心编号从
0开始，对应/proc/cpuinfo里processor字段的值，不是物理封装序号（如Intel超线程的逻辑核要小心区分）
绑定前必须检查CPU可用性与权限
常见错误现象：sched_setaffinity 返回-1且errno == EINVAL，多数是因为试图绑定到不存在的CPU编号，或进程被cgroups限制了CPU集。
安全做法：
立即学习“C++免费学习笔记（深入）”；
- 读取
/sys/devices/system/cpu/online获取当前可用CPU范围（如0-3或0,2,4,6） - 调用
sched_getaffinity(0, sizeof(cpu_set_t), &old_set)先保存原亲和性，便于恢复 - 普通用户进程默认可绑定任意在线CPU；但若运行在容器或systemd service中，需确认
CPUAffinity=未被覆盖，或cgroup v2的cpuset.cpus已开放目标核心
pthread_setaffinity_np vs sched_setaffinity怎么选
关键区别不在功能，而在适用对象和线程模型：
-
pthread_setaffinity_np接收pthread_t，适合明确控制某个std::thread——先join()或确保线程已启动再调用，否则行为未定义 -
sched_setaffinity接收线程ID（pid_t），对std::thread需用gettid()获取LWP ID（注意：glibc未暴露该函数，得用syscall(SYS_gettid)） -
_np后缀表示“non-portable”，但实际在glibc/Linux上稳定可用；sched_*系列是POSIX.1b标准，可移植性略高，但操作当前线程更直接 - 性能无差异，两者最终都触发同一内核路径；但
pthread_setaffinity_np自动处理线程取消点，更符合pthread语义
绑定后验证是否生效
别只信返回值。真实场景中，绑定可能被调度器后续调整（尤其当目标CPU离线或负载突变），必须主动验证：
- 用
sched_getaffinity(0, sizeof(cpu_set_t), &check_set)读回当前亲和集，再遍历CPU_ISSET(cpu, &check_set)确认目标位被置位 - 观察
/proc/[pid]/status中Cpus_allowed_list字段，或用taskset -p [pid]命令行工具交叉验证 - 注意：
std::thread构造后立即绑定可能失败（线程尚未创建LWP），建议在线程函数入口第一行执行绑定逻辑 - 如果绑定了超线程对（如CPU 0 和 1），而应用是纯计算密集型，反而可能因共享ALU导致性能下降——物理核心数比逻辑核数更关键
最易忽略的一点：CPU亲和性不传递。子线程、std::async 启动的任务、甚至fork()后的子进程，都不会继承父线程的CPU绑定，必须各自显式设置。
