taskset -p 仅显示进程允许运行的cpu核集合（调度亲和性），而非实时运行核；真正获取实时分布需高频采样，推荐用/proc/pid/stat第39字段轮询或pidstat -t -p 0.01，c++可直接读取该字段实现轻量无特权监控。
Linux 下用 taskset 查当前进程绑定的 CPU 核心不等于“实时分布图”
很多人以为 taskset -p <pid></pid> 能看到进程“跑在哪些核上”，其实它只显示调度亲和性（affinity）掩码——也就是允许运行的核集合，不是实际正在运行的核。进程可能被内核动态迁移到任意允许的核心上，taskset 完全不反映瞬时状态。
真正要捕获“实时分布”，本质是高频采样每个时间点进程在哪颗 CPU 上执行。Linux 提供了两种可靠路径：基于 /proc/<pid>/stat</pid> 的轮询，或使用 perf 事件追踪。
-
/proc/<pid>/stat</pid>第 39 字段（processor）记录上次调度时所在的 CPU 编号，但它是快照，非连续；采样间隔需 ≤10ms 才勉强称“实时”，且频繁读取有开销 -
perf record -e sched:sched_switch -p <pid></pid>可精确捕获每次上下文切换，包括从哪个 CPU 切出、切到哪个 CPU，但需要 root 权限，且输出是二进制事件流，需用perf script解析 - 普通用户更可行的是用
pidstat -t -p <pid> 0.01</pid>（单位秒），它底层调用/proc并做简单聚合，输出每 10ms 的 CPU ID，可重定向后用 awk 统计频次
C++ 里直接读 /proc/<pid>/stat</pid> 获取瞬时 CPU ID
这是最轻量、无需特权的方式。关键字段是第 39 个（以空格分隔），对应内核中 task_struct->cpu 的快照值。注意：该值只在进程被调度器选中执行时更新，休眠/阻塞态下不会变，所以连续读到相同值不意味一直占着那个核。
示例代码片段：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
#include <fstream>
#include <string>
#include <vector>
#include <sstream>
int get_current_cpu(int pid) {
std::ifstream f("/proc/" + std::to_string(pid) + "/stat");
if (!f.is_open()) return -1;
std::string line;
std::getline(f, line);
std::istringstream iss(line);
std::vector<:string> fields;
std::string field;
while (std::getline(iss, field, ' ')) {
fields.push_back(field);
}
if (fields.size() >= 39) {
return std::stoi(fields[38]); // 索引从 0 开始，第 39 字段是 index 38
}
return -1;
}
</:string></sstream></vector></string></fstream>
- 字段索引容易错：man proc 明确写第 39 项是 “processor” —— 但 C++ vector 是 0-based，所以取
fields[38] - 必须检查
fields.size()，否则越界访问导致崩溃；某些内核配置下字段数可能不同 - 不要用
std::stoi直接转，建议先strtol并检查errno，避免非法字符（如字段含括号时曾有旧版内核 bug）
用 perf_event_open 系统调用实现无 root 的细粒度追踪（C++ 原生）
如果你真需要纳秒级精度、且不想依赖外部工具，perf_event_open 是唯一选择。它允许普通用户监听本进程的调度事件（PERF_TYPE_SCHEDULER），但仅限于自己创建的子进程或通过 ptrace 附加的进程——对自身主线程的 sched_switch 事件，默认禁止，除非开启 kernel.perf_event_paranoid = 2（需管理员临时设置）。
实际更稳妥的做法是：fork 出子进程，在子进程中用 perf_event_open 监听自身调度，并把 CPU 切换事件写入 pipe 或 shared memory，父进程读取并绘图。这样避免权限问题，也规避主线程自监控的限制。
- 事件类型必须用
PERF_COUNT_SW_CPU_MIGRATIONS或PERF_COUNT_SW_PAGE_FAULTS等软件事件，硬件事件（如 cycles）会显著拖慢性能 -
read()返回的struct read_format中，cpu字段才是当前 CPU ID，不是pid或tid - 每次
read()可能返回多个事件，需循环解析，不能假设一次只一个
可视化“分布图”的实际难点不在采集，而在定义“实时”
所谓“分布图”，如果指每秒各核心负载百分比，用 top -b -n1 或 mpstat -P ALL 1 1 更准；如果指单个进程在 N 毫秒内出现在哪些核上、停留多久，就必须接受两个事实：
- Linux 调度器本身不保证“公平分配”，短时突发任务可能集中打满单核，而长周期任务才体现跨核迁移
- 任何采样都有 aliasing 风险：10ms 采样一次，但进程在两采样点之间完成 5 次切换，你只会看到首尾两个 CPU ID
- 物理核心 vs 逻辑核心（超线程）要区分清楚：
lscpu输出的CPU(s)是逻辑数，Core(s) per socket才是物理核心数；/sys/devices/system/cpu/cpu*/topology/core_id可查映射关系
真正能落地的方案通常是：用 pidstat 采样 → 导出 CSV → 用 Python pandas 统计每核出现次数 → 用 matplotlib 绘热力图（横轴时间，纵轴 CPU ID）。C++ 本身不适合做这种轻量聚合和绘图，硬写反而增加维护成本。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
