taskset 是用于实时诊断与干预CPU亲和性的工具，非教程式学习工具；查进程绑定CPU应优先用 taskset -cp PID，注意十六进制掩码需转换，多线程需逐个检查TID，启动时绑定优于运行后绑定，掩码允许多核则仍可动态调度，Python可用 os.sched_setaffinity() 更精准控制。
taskset 不是用来“教程式学习”的工具，而是你在遇到真实调度问题时，拿来就用、改完即生效的诊断与干预手段。它不是银弹，但对 CPU 缓存局部性差、线程频繁迁移、或需隔离关键服务的场景，往往立竿见影。
怎么查一个进程当前绑在哪些 CPU 上？
最常用也最容易出错的是只看 taskset -p PID，却忽略它默认输出的是十六进制掩码——比如返回 3f，你得知道这是 6 位二进制 00111111，对应 CPU 0–5 全开；而 0x5 是 0101，只开 CPU 0 和 2。
- 更直观的方式是加
-c参数：taskset -cp PID，直接显示0,2-3这类列表格式 - 注意：
taskset -p查的是主线程（TID 等于 PID）的亲和性；多线程程序中，其他线程可能有不同设置，需用ps -T -p PID找出所有 TID，再逐个查taskset -p TID - 如果返回 “Operation not permitted”，说明该进程启用了
cap_sys_nice限制，或你非 root 且目标进程不属于你——这不是 bug，是内核安全机制
启动新进程时就绑定 CPU，别等它跑歪了再拉回来
事后绑定（taskset -cp）虽可行，但无法改变已分配的内存页 NUMA 节点、TLB 状态或缓存预热路径。真正要压测、跑实时任务、或做性能基线对比，必须从启动那一刻就固化亲和性。
- 正确写法：
taskset -c 1,3-4 ./myserver --port 8080——-c后紧跟 CPU 列表，再跟命令，顺序不能错 - 错误写法：
taskset -c 1,3-4 --port 8080 ./myserver—— 把参数塞到命令前面，taskset会把--port当作自己的选项报错 - 若需绑定全部线程（包括后续 fork 出的子线程），加上
-a：taskset -ac 0,2 python workload.py
为什么绑了 CPU，top 里还是看到它在跳核？
这是最常被误解的现象：taskset 设置的是 **调度器允许运行的 CPU 集合**，不是“永远钉死某一个核”。只要亲和性掩码里包含多个 CPU，内核仍可在其中动态调度——这是为了负载均衡，不是失效。
- 想彻底固定到单核？掩码只能设一个位，例如
taskset -c 2或taskset 0x4（CPU 2 对应第 3 位，即 2²=4） - 想验证是否真生效？用
ps -eo pid,psr,comm | grep myserver，其中psr列显示当前实际运行的 CPU 号——连续观察几秒，若始终为 2，说明成功；若在 2 和 3 之间跳，说明亲和性掩码里同时包含了 2 和 3 - 注意：中断（IRQ）、内核线程、以及其他非用户进程不受你的
taskset影响，它们的调度独立
Python 用户别绕远路：用 os.sched_setaffinity() 更可控
如果你的程序本身就是 Python 写的，硬套 shell 的 taskset 启动不仅多一层依赖，还难以在运行中动态调整（比如根据负载切核）。直接调系统 API 更干净。
import os import sys绑定当前进程到 CPU 0 和 2
os.sched_setaffinity(0, {0, 2})
验证
print("Current affinity:", os.sched_getaffinity(0))
-
os.sched_setaffinity(pid, cpuset)中pid=0表示当前进程，cpuset是 int 集合（不是字符串！） - 该调用会抛
OSError（如权限不足、CPU 不存在），务必 try/catch；失败时不会静默忽略 - 子进程默认继承亲和性，但若用
subprocess.Popen并显式设置了start_new_session=True，可能重置——这点容易漏测
taskset 的本质不是“高级功能”，而是对内核 sched_setaffinity() 系统调用的一层薄封装。它的威力不在于多酷炫，而在于足够轻、足够快、足够直接——只要你清楚自己要锁住哪几个核、为什么锁、以及锁不住时该去看哪条错误信息。
