C++如何获取当前线程的CPU亲和性-C++-PHP中文网

linux下用pthread_getaffinity_np读取线程亲和性需先cpu_zero初始化cpu_set_t，传入正确大小，检查返回值；windows用getthreadgroupaffinity；跨平台时不能依赖std::thread::id或native_handle()，而应创建时捕获原生句柄。

c++如何获取当前线程的cpu亲和性

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

Windows下没有直接等价API，得绕道`GetThreadGroupAffinity`

Windows线程亲和性分两层：传统SetThreadAffinityMask操作的是单个处理器组内的掩码，而现代多NUMA系统用GROUP_AFFINITY结构描述跨组绑定。获取当前值必须用GetThreadGroupAffinity，且仅对当前线程有效（传GetCurrentThread()句柄）。

容易踩的坑是误以为GetProcessAffinityMask能反映线程状态——它只返回进程默认掩码，不体现线程运行时被显式设置过的亲和性。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

需在编译时定义_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构造完成但尚未执行用户代码前，亲和性可能还未应用；而在长时间运行的线程里，中间可能被其他代码（比如第三方库的线程池）悄悄修改过掩码。