正确答案是：必须用CPU_ZERO初始化cpuset、传入sizeof(cpuset)、用CPU_ISSET遍历且上限取sysconf(_SC_NPROCESSORS_ONLN)，因cpu_set_t为不透明类型，直接位操作或硬编码大小会导致越界或移植错误。
直接调用 sched_getaffinity(0, sizeof(cpuset), &cpuset) 即可获取当前线程的 CPU 亲和性掩码，但必须确保 cpuset 已用 CPU_ZERO 初始化，且传入的 sizeof(cpuset) 是变量实际大小——硬写 sizeof(cpu_set_t) 或 CPU_SETSIZE 会导致越界或截断。
为什么 sched_getaffinity 返回的 CPU 集比物理核心数还小
这不是 bug，而是多层约束叠加后的生效结果：
- 进程启动时被
taskset或numactl限制过，子线程会继承该亲和性 - 容器环境（Docker/K8s）通过 cgroups v1 的
cpuset.cpus或 v2 的cpuset.cpus.effective进一步收窄可见 CPU 范围 - 内核节能策略（如
sysctl kernel.sched_smt_power_savings=1）可能 runtime 隐藏部分逻辑核 - 若你曾调用
pthread_setaffinity_np但未检查返回值，失败后仍继续执行，也会导致掩码与预期不符
验证方式：运行中执行 cat /proc/self/status | grep Cpus_allowed，输出应与 sched_getaffinity 结果完全一致；不一致说明代码里某处修改失败却未处理错误。
如何安全地解析和遍历 cpu_set_t 掩码
cpu_set_t 是不透明类型，不能直接按位操作或假设其内存布局。正确做法是用标准宏逐个检查：
- 先用
sysconf(_SC_NPROCESSORS_ONLN)获取系统在线逻辑核总数，避免遍历越界 - 对每个
i（从 0 到总数 −1），调用CPU_ISSET(i, &cpuset)判断是否允许运行 - 不要用
memcpy或指针强转读取cpu_set_t内部字节——glibc 可能在不同架构下改变其实现
示例片段：
sched_getaffinity
- 用
gettid()获取 tid 后传给sched_getaffinity(tid, ...)—— 必须确保该线程尚未退出，否则返回ESRCH - 在
std::thread构造后立即对t.native_handle()调用 —— 此时线程可能还没完成内核态创建，pthread_setaffinity_np会失败，但sched_getaffinity若传0是安全的（它只查调用者自身） - 误以为
std::this_thread::get_id()和 CPU 核心编号有关联 —— 它只是 std::thread 内部抽象 ID，和 OS 线程 ID、调度状态都无映射关系
真正验证是否绑成功，只有两种可靠方式：pthread_getaffinity_np(pthread_self(), sizeof(set), &set) 在线程函数内查，或外部用 taskset -p $(pidof your_app)。
最常被忽略的一点：即使 sched_getaffinity 成功返回，也不代表线程“正在”运行在那些核上——它只表示“允许运行”的集合。线程大部分时间阻塞在 IO 或锁上时，调度器根本不会把它放到任何核去执行，此时查到的掩码毫无性能意义。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
