绑核后性能未提升的主因是策略失当或瓶颈错判：需验证绑定是否生效、核是否干净合适、应用是否存在串行瓶颈，并用P99延迟等稳定性指标而非平均吞吐评估收益。
进程绑核后性能没提升，不是绑核失效，而是“绑对了位置，却没解决真问题”。核心要确认三件事：绑核是否生效、绑核策略是否合理、其他瓶颈是否掩盖了收益。下面分四类常见原因展开说明。
一、绑核操作本身没生效
很多情况下，你以为绑成功了，其实线程仍在自由调度。
- 用 taskset -p <pid> 查看进程当前亲和性掩码，输出如 0x00000003 表示只允许在 CPU0 和 CPU1 运行；但要注意：这只是进程的默认亲和性，新创建的线程可能继承它，也可能被代码显式重设（比如 Java 的
ForkJoinPool或 Netty 的EventLoop会自行调用sched_setaffinity） - 更可靠的方式是查线程级绑定：用 ps -T -o pid,tid,psr,comm -p <pid>，其中 psr 列显示该线程当前实际运行在哪颗 CPU 上；持续观察几秒，看是否稳定落在指定核上
- 容器环境要额外注意：Docker 默认不传递亲和性，Kubernetes 需显式配置
cpuAffinity或使用cpuset.cpuscgroup 参数，否则 host 层的 taskset 对容器内进程无效
二、绑核策略与 workload 不匹配
把线程绑到某个核上只是手段，关键要看这个核是否“干净”、是否“合适”。
- 没做 CPU 隔离：即使绑定了 CPU2，但如果该核上还跑着定时器中断、ksoftirqd、其他用户进程或容器，缓存污染和 TLB 冲突依然严重。应配合 isolcpus= 内核启动参数 + systemd.cpu_affinity 隔离干扰源
- 大小核混用误判：在 Intel 12/13/14 代或 AMD 新平台，CPU0 可能是能效核（E-core），而你绑过去的是“最闲”的核，却不是“最强”的核。用 lscpu | grep "Core(s) per socket\|CPU\(s\)" 结合 cat /sys/devices/system/cpu/cpu*/topology/core_type（值为 0=performance，1=efficiency）识别 P/E 核分布
- NUMA 节点错配：若绑核跨 NUMA 节点（比如绑了 CPU0 和 CPU8，但它们属于不同 node），内存访问延迟飙升。用 numactl --hardware 查节点拓扑，优先在同 node 内选核，并用 numactl --cpunodebind=<node> --membind=<node> 同时约束 CPU 和内存
三、应用自身存在串行瓶颈
绑核只能让并行部分跑得更稳，不能把单线程逻辑变多线程。
- 用 perf top -p <pid> 或 perf record -g -p <pid> && perf report 看热点函数：如果 90% 时间耗在
pthread_mutex_lock、__futex_abstimed_wait_common或某个串行计算函数里，说明锁竞争或算法结构才是瓶颈，绑核无济于事 - 检查线程数是否真正扩展：ps -T -p <pid> | wc -l 看线程总数；再结合 htop 按 CPU 分组查看，确认多个线程是否真在不同核上活跃运行，而非全部阻塞等待同一资源
- 典型陷阱：Java 应用开启 G1 垃圾回收时，如果
ConcGCThreads设置过低，或者堆过大导致 Mixed GC 频繁，GC 线程本身也会成为单点瓶颈，此时绑核对业务线程无效
四、性能指标误读或观测窗口不合适
绑核收益往往体现在延迟稳定性、P99/P999 指标上，而不是平均吞吐或 CPU 使用率。
- CPU 使用率下降反而是好事：绑核减少跨核迁移后，缓存命中率上升，完成同样任务所需指令周期减少，CPU 占用率可能反而降低，但响应时间更短、抖动更小
- 必须用延迟敏感型指标验证：比如网关场景看 P99 请求延迟、实时风控看 处理毛刺率、音视频转码看 帧间延迟标准差；单纯看 QPS 或平均 RT 容易忽略收益
- 观测时间不足：绑核效果在长稳态下才明显，建议压测至少持续 5 分钟以上，避开启动预热期和 GC 尖峰期，用 latencytop 或 eBPF 工具（如
bpftrace -e 'profile:hz:99 { @[ustack] = count(); }'）捕获真实延迟分布
