taskset是最直接、最低侵入的绑核工具，用于将进程固定在指定CPU核心上以减少调度抖动和提升缓存命中率，但仅控制调度器允许范围，不阻止中断等抢占，需配合isolcpus或cgroups实现深度隔离。
taskset 是最直接、最低侵入的方式，能快速把进程钉死在指定物理核心上，但必须清楚：它只控制调度器“允许在哪跑”，不阻止内核其他机制（如中断、软中断、ksoftirqd）抢占同一核心——真要隔离，得配合 isolcpus 或 cgroups。
用 taskset -c 绑定运行中进程
对已启动的进程改绑，是最常见需求。关键不是“能不能绑”，而是“绑完是否生效”——很多用户执行完 taskset -pc 2,5 1234 就以为完事了，其实得立刻验证。
- 先确认目标 CPU 编号真实存在：
lscpu看CPU(s):总数，并注意NUMA node(s):和NUMA node0 CPU(s):分布，避免跨 NUMA 节点绑核导致内存延迟飙升 -
taskset -pc 2,5 1234执行后，必须立刻跟一句taskset -cp 1234查看输出是否真变成2,5；若仍显示旧值，说明进程可能有子线程继承了原亲和性，或被 systemd 的CPUAffinity覆盖 - 绑定后观察
pidstat -t -p 1234 1，看%CPU是否稳定出现在指定 CPU 列（如cpu2），而不是跳变
启动时用 taskset -c 固化亲和性
比动态绑定更可靠，尤其适合脚本、服务、容器入口。但要注意 shell 解析顺序和参数传递陷阱。
- 写法必须是
taskset -c 0,2 ./myapp --arg1 value，不能写成taskset -c0,2 ./myapp（少空格会导致-c0被当做一个选项，报错invalid option -- '0'） - 如果命令带重定向或管道，
taskset只绑定第一个进程：taskset -c 1 cat /proc/cpuinfo | grep model中只有cat被绑，grep不受控 - Python/Java 等解释型程序需注意：JVM 启动后会派生多个线程（如 GC 线程），
taskset只影响主线程，后续线程默认继承父亲和性，但某些 JVM 参数（如-XX:+UseParallelGC）可能绕过该继承
systemd 配置 CPUAffinity 持久生效
适用于长期运行的服务，重启后自动恢复绑定，但语法极其严格，错一个空格就静默失效。
-
CPUAffinity值只能是空格分隔的数字或范围，例如CPUAffinity=0 2 4-6，**不支持逗号、不支持混合写法（如0,2）**，写错不会报错，只会回退到默认全核可用 - 若服务由
Forking类型启动（如传统 daemon），必须确保ExecStart启动的是最终主进程 PID，否则CPUAffinity绑的是 fork 出来的子进程，而主进程仍在原核心跑 - 修改后必须执行
sudo systemctl daemon-reload，仅restart不够；验证方式是systemctl show myapp.service | grep CPUAffinity，再查实际进程：ps -o pid,comm,psr -p $(systemctl show --property MainPID myapp.service | cut -d= -f2)
为什么 taskset 绑了还是跑偏？常见干扰源
绑核失效往往不是 taskset 本身的问题，而是被更高优先级的调度策略覆盖或硬件层干扰。
-
IRQ（硬中断）默认绑定在 CPU 0，高频率网络包或磁盘 IO 会让 CPU 0 持续忙碌，即使你的进程绑在 CPU 2，网卡软中断（softirq）仍可能在 CPU 0 触发并间接拖慢整个系统响应 - 内核参数
isolcpus=2,5启动时加入/etc/default/grub，才能让 CPU 2 和 5 真正“隔离”——既不跑普通进程，也不处理大部分中断，这是taskset无法做到的深度隔离 - 容器场景下，Docker/K8s 默认不限制
cpuset，即使宿主机用taskset绑了进程，容器 runtime 可能通过cpuset.cpuscgroup 覆盖该设置，此时应优先用--cpuset-cpus="2,5"启动容器
真正稳定的绑核，从来不是单靠一个 taskset 命令。它只是第一层开关，后面还得看 NUMA 拓扑是否匹配、中断是否分流、内核是否隔离、容器是否越权——漏掉任意一环，都可能让 P99 延迟悄悄爬升。
