sched_getaffinity是Linux获取进程CPU亲和性掩码的唯一标准接口，需传入pid_t和对齐的cpu_set_t缓冲区，返回值仅指示成败，掩码存于缓冲区中；/proc/<pid>/stat的processor字段仅记录最近调度CPU编号，不反映亲和性约束。
Linux下用sched_getaffinity查进程CPU亲和性掩码
进程的“CPU亲和性”不是实时负载图，而是内核允许该进程运行在哪几个物理核心上的位掩码。想看分布，得先拿到这个掩码，再解码成核心编号列表。sched_getaffinity是唯一标准接口，传入pid_t和缓冲区即可。注意：传0表示查当前进程；缓冲区大小必须按CPU_SETSIZE字节对齐，且需用CPU_ZERO/CPU_ISSET宏操作，不能直接当整数读。
常见错误是把返回值当掩码值——它只返回0（成功）或-1（失败），掩码存在你传入的cpu_set_t*里。示例片段：
cpu_set_t set;
CPU_ZERO(&set);
if (sched_getaffinity(0, sizeof(set), &set) == 0) {
for (int i = 0; i < CPU_SETSIZE; i++) {
if (CPU_ISSET(i, &set)) {
printf("core %d\n", i); // 实际可用核心编号
}
}
}
为什么/proc/<pid>/stat里的processor字段不能反映亲和性
/proc/<pid>/stat第39字段（processor）只记录进程**最近一次被调度时所在的CPU编号**，和亲和性掩码完全无关。它甚至可能为-1（未调度过）或超出物理核心数（比如超线程逻辑核编号）。想确认亲和性是否生效，不能靠这个字段——它不体现约束范围，只反映瞬时位置。
真正能交叉验证亲和性的路径是：/proc/<pid>/status里的CapEff行没用，但Threads和voluntary_ctxt_switches变化趋势可间接提示：若亲和性设为单核而nonvoluntary_ctxt_switches飙升，说明频繁被抢占挤出，可能触发了迁移惩罚。
立即学习“C++免费学习笔记（深入）”；
获取实时负载需结合/proc/stat与进程时间片统计
所谓“各核心负载分布图”，本质是两件事拼起来：① 进程被允许跑哪些核（亲和性），② 它在这些核上实际花了多少时间。后者得自己算：/proc/<pid>/stat第14/15字段（utime/stime）是累计用户/系统态jiffies，除以HZ得秒数；再对比/proc/stat里每个cpuN行的总jiffies增量，才能估算占比。
关键限制：utime/stime是进程全局累计值，不按核心拆分。Linux内核不记录“某进程在cpu3上跑了多久”，只记总时间。所以严格来说，不存在官方支持的每核负载明细——所有可视化工具（如htop）都是用采样+启发式推测（比如根据最近调度位置加权）。
实操建议：
- 用
sched_getaffinity确定合法核心集合 - 轮询
/proc/<pid>/stat和/proc/stat，计算单位时间内的jiffies差值 - 用
sched_setaffinity临时绑定到单核，观察utime增速是否与该核cpuN总忙时比例强相关 - 避免用
taskset -p查——它只读sched_getaffinity结果，不反映真实运行分布
glibc封装与跨平台陷阱
Windows没有sched_getaffinity对应物，Win32用GetProcessAffinityMask，返回两个DWORD_PTR（低32位/高32位掩码），且核心编号从0开始但最大支持64核（取决于sizeof(DWORD_PTR)）。macOS更麻烦：pthread_getaffinity_np非标准，且默认禁用——需编译时加-D_DARWIN_C_SOURCE，运行时还可能因SMP策略返回空集。
所以写跨平台代码时，别试图抽象出统一接口。宁可：
- Linux走
sched_getaffinity - Windows走
GetProcessAffinityMask+GetActiveProcessorCount - macOS直接放弃亲和性查询，或fallback到
sysctlbyname("hw.ncpu")获核心数
亲和性本身是调度策略细节，不是进程状态快照；所谓“分布图”其实是动态采样+合理假设的结果，任何工具给出的热力图都带推测成分。真要精确归因，得用perf record -e sched:sched_switch -p <pid>抓上下文切换事件，再按prev_cpu/next_cpu字段聚合——但这已超出常规监控范畴。
