Linux下用pthread_getaffinity_np读取线程亲和性需先CPU_ZERO初始化cpu_set_t，传入正确大小，检查返回值；Windows用GetThreadGroupAffinity；跨平台时不能依赖std::thread::id或native_handle()，而应创建时捕获原生句柄。
Linux下用pthread_getaffinity_np读取线程亲和性
Linux是唯一提供标准POSIX扩展接口支持线程级CPU亲和性查询的主流系统。关键函数是pthread_getaffinity_np，它需要传入一个cpu_set_t结构体来接收结果。
常见错误是忽略CPU_ZERO初始化或误用sizeof(cpu_set_t)作为参数长度——实际应调用CPU_ALLOC或确保cpu_set_t足够大（通常用CPU_SETSIZE上限）。
-
cpu_set_t必须先用CPU_ZERO(&set)清零，否则未初始化位可能导致pthread_getaffinity_np返回EINVAL - 调用前检查返回值：非0表示失败，常见
ESRCH（线程已退出）、EPERM（权限不足） - 示例片段：
cpu_set_t set; CPU_ZERO(&set); int ret = pthread_getaffinity_np(pthread_self(), sizeof(cpu_set_t), &set); if (ret == 0) { for (int i = 0; i < CPU_SETSIZE; ++i) { if (CPU_ISSET(i, &set)) printf("CPU %d\n", i); } }
Windows下没有直接等价API，得绕道GetThreadGroupAffinity
Windows线程亲和性分两层：传统SetThreadAffinityMask操作的是单个处理器组内的掩码，而现代多NUMA系统用GROUP_AFFINITY结构描述跨组绑定。获取当前值必须用GetThreadGroupAffinity，且仅对当前线程有效（传GetCurrentThread()句柄）。
容易踩的坑是误以为GetProcessAffinityMask能反映线程状态——它只返回进程默认掩码，不体现线程运行时被显式设置过的亲和性。
立即学习“C++免费学习笔记（深入）”；
- 需在编译时定义
_WIN32_WINNT>= 0x0601（Windows 7+）才能使用GROUP_AFFINITY - 返回的
Group字段标识处理器组编号，Mask是该组内CPU位图；若系统只有1个组，Group恒为0 - 示例关键行：
GROUP_AFFINITY affinity; if (GetThreadGroupAffinity(GetCurrentThread(), &affinity)) { printf("Group: %u, Mask: 0x%llx\n", affinity.Group, affinity.Mask); }
跨平台封装要注意std::thread::id无法直接转系统线程句柄
C++标准库的std::thread不暴露底层线程ID映射关系，std::thread::get_id()返回的是实现定义的std::thread::id，不能安全用于pthread_getaffinity_np或GetThreadGroupAffinity。必须在创建线程时就捕获原始句柄。
典型错误写法是试图对std::thread对象调用native_handle()后直接传给系统API——虽然native_handle()返回pthread_t或HANDLE，但其生命周期依赖std::thread对象是否join/detach，且Windows下HANDLE可能已被关闭。
- Linux：保存
pthread_self()结果比调用std::thread::native_handle()更可靠 - Windows：创建线程后立即用
GetCurrentThread()并DuplicateHandle保留句柄副本（注意权限标志THREAD_QUERY_INFORMATION） - 不要在lambda捕获中隐式使用
this去调用封装函数——线程启动时机可能导致this已析构
亲和性查询结果可能滞后于实际调度位置
操作系统允许线程在亲和性掩码范围内自由迁移，pthread_getaffinity_np或GetThreadGroupAffinity返回的是“允许运行的CPU集合”，不是“当前正在运行的CPU”。想查实时位置得用sched_getcpu()（Linux）或GetCurrentProcessorNumber()（Windows），但这两个函数开销较大且不保证原子性。
性能敏感场景下，频繁调用亲和性查询本身就会干扰调度器——尤其在高负载时，查询动作可能触发线程迁移，导致后续查询结果与前一次不一致。
-
sched_getcpu()返回整数CPU编号，无需额外结构体，但glibc版本需≥2.6 - Windows的
GetCurrentProcessorNumber()仅返回当前组内编号，跨组场景需配合GetCurrentProcessorNumberEx和PROCESSOR_NUMBER结构 - 如果目标是调试线程绑定效果，建议结合
/proc/[pid]/status里的Cpus_allowed_list字段做交叉验证
std::thread构造完成但尚未执行用户代码前，亲和性可能还未应用；而在长时间运行的线程里，中间可能被其他代码（比如第三方库的线程池）悄悄修改过掩码。 
