C++如何获取当前进程在各物理CPU核心上的负载亲和性分布图-C++-PHP中文网

sched_getaffinity是linux获取进程cpu亲和性掩码的唯一标准接口，需传入pid_t和对齐的cpu_set_t缓冲区，返回值仅指示成败，掩码存于缓冲区中；/proc//stat的processor字段仅记录最近调度cpu编号，不反映亲和性约束。

c++如何获取当前进程在各物理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 

<h3>为什么<code>/proc/<pid>/stat</pid></code>里的<code>processor</code>字段不能反映亲和性</h3>
<p><code>/proc/<pid>/stat</pid></code>第39字段（<code>processor</code>）只记录进程**最近一次被调度时所在的CPU编号**，和亲和性掩码完全无关。它甚至可能为-1（未调度过）或超出物理核心数（比如超线程逻辑核编号）。想确认亲和性是否生效，不能靠这个字段——它不体现约束范围，只反映瞬时位置。</p>
<p>真正能交叉验证亲和性的路径是：<code>/proc/<pid>/status</pid></code>里的<code>CapEff</code>行没用，但<code>Threads</code>和<code>voluntary_ctxt_switches</code>变化趋势可间接提示：若亲和性设为单核而<code>nonvoluntary_ctxt_switches</code>飙升，说明频繁被抢占挤出，可能触发了迁移惩罚。</p>

<h3>获取实时负载需结合<code>/proc/stat</code>与进程时间片统计</h3>
<p>所谓“各核心负载分布图”，本质是两件事拼起来：① 进程被允许跑哪些核（亲和性），② 它在这些核上实际花了多少时间。后者得自己算：<code>/proc/<pid>/stat</pid></code>第14/15字段（<code>utime</code>/<code>stime</code>）是累计用户/系统态jiffies，除以<code>HZ</code>得秒数；再对比<code>/proc/stat</code>里每个<code>cpuN</code>行的总jiffies增量，才能估算占比。</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架"><img
														src="https://img.php.cn/upload/skill/000/000/081/178988956499722.jpg" alt="C++ 算法竞赛自动化测试数据生成与校验框架" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架" class="overflowclass">C++ 算法竞赛自动化测试数据生成与校验框架</a>
													<p class="overflowclass">根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill4025" title="C++ 算法竞赛自动化测试数据生成与校验框架" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>
<p>关键限制：<code>utime/stime</code>是进程全局累计值，不按核心拆分。Linux内核不记录“某进程在cpu3上跑了多久”，只记总时间。所以严格来说，不存在官方支持的每核负载明细——所有可视化工具（如<code>htop</code>）都是用采样+启发式推测（比如根据最近调度位置加权）。</p>
<p>实操建议：</p>

用sched_getaffinity确定合法核心集合
轮询/proc/<pid>/stat</pid>和/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></pid>抓上下文切换事件，再按prev_cpu/next_cpu字段聚合——但这已超出常规监控范畴。