在多核系统中，操作系统的调度器会根据负载情况把线程在不同核心之间来回迁移，这虽然保证了整体负载均衡，但对延迟敏感或缓存密集型的程序来说，迁移意味着L1、L2缓存频繁失效，性能抖动明显。CPU亲和性绑定就是把进程或线程固定到指定核心上运行的技术手段，在Fedora这类较新的发行版上，有多种方式可以实现绑定。
本文从命令行工具、编程接口和服务配置三个层面展开，讨论在Fedora上如何落地CPU亲和性，并分析哪些场景适合绑定，哪些场景反而会适得其反。
使用taskset命令快速绑定核心
taskset是util-linux软件包自带的工具，Fedora默认安装，是查看和设置CPU亲和性最直接的方式。它通过CPU集合掩码来指定允许运行的核心，掩码可以用十六进制表示，也可以用-c参数直接写核心编号列表。
启动新进程并绑定到第0号和第2号核心，可以这样写：
# 以4个线程运行stress-ng，并绑定到0号和2号核心 taskset -c 0,2 stress-ng --cpu 4 --timeout 60s # 查看某个已运行进程当前的核心亲和性 taskset -pc 12345 # 修改正在运行进程的亲和性，将其迁移到4到7号核心 taskset -pc 4-7 12345
第一条命令输出类似pid 12345's current affinity list: 0-3，说明该进程目前可以调度到0到3号核心；执行修改命令后再查看，列表就变成4-7了。需要注意的是，修改亲和性不会立刻中断进程，调度器会在下一个调度点把线程迁移到新核心上。
还有一个细节值得注意：父进程设置的亲和性会被子进程继承。因此如果先用taskset启动了一个脚本，脚本里再拉起的其他进程也会被限制在同一组核心上。这一点有时是想要的效果，有时却会造成意外的资源争抢，使用时要留意进程树的结构。可以用taskset -pc $$查看当前shell自身的亲和性，确认环境是否已经被上层限制过。
在代码中通过sched_setaffinity精确控制
命令行工具适合一次性任务，但对于多线程服务程序，往往需要程序自己控制每个线程落在哪个核心上，这时就要用到Linux提供的系统调用。glibc封装了sched_setaffinity和pthread_setaffinity_np两个函数，前者针对进程级PID，后者针对线程。
下面是一个C语言的完整示例，创建两个线程分别绑定到不同核心：
#define _GNU_SOURCE
#include <pthread.h>
#include <stdio.h>
#include <sched.h>
#include <string.h>
void *worker(void *arg) {
int core = *(int *)arg;
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(core, &cpuset);
// 将当前线程绑定到指定核心
int ret = pthread_setaffinity_np(pthread_self(),
sizeof(cpuset), &cpuset);
if (ret != 0) {
fprintf(stderr, "绑定核心失败: %s\n", strerror(ret));
}
// 查询并确认绑定结果
CPU_ZERO(&cpuset);
pthread_getaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
printf("线程运行在核心: ");
for (int i = 0; i < CPU_SETSIZE; i++) {
if (CPU_ISSET(i, &cpuset)) printf("%d ", i);
}
printf("\n");
return NULL;
}
int main(void) {
pthread_t t1, t2;
int core1 = 0, core2 = 2;
pthread_create(&t1, NULL, worker, &core1);
pthread_create(&t2, NULL, worker, &core2);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
return 0;
}
编译时记得加上宏定义和pthread库：gcc -D_GNU_SOURCE affinity.c -o affinity -lpthread。运行后两个线程会分别固定在0号和2号核心上。对于Go、Rust、Java等语言，运行时或标准库也提供了类似能力，例如Go可以通过runtime.LockOSThread配合cgo调用实现，JVM则一般借助操作系统的任务集配置来间接完成。
编程接口的优势在于灵活性：可以根据NUMA拓扑把网络收包线程绑到网卡所在NUMA节点的核心上，把计算线程绑到同一节点的内存附近，避免跨节点访问内存带来的额外延迟。Fedora上可以用lscpu或numactl --hardware查看NUMA拓扑，确定哪些核心属于哪个节点。
systemd服务与持久化绑定配置
临时绑定在重启后就失效了，对于生产环境的服务，需要把亲和性配置固化下来。现代Fedora使用systemd管理服务，而systemd原生支持CPU亲和性设置，只需在unit文件中加一行配置即可。
# /etc/systemd/system/myapp.service [Unit] Description=My CPU-bound Application [Service] ExecStart=/usr/local/bin/myapp CPUAffinity=0 1 2 3 # 也可以写成范围形式 # CPUAffinity=0-3 [Install] WantedBy=multi-user.target
修改后执行systemctl daemon-reload && systemctl restart myapp即可生效，可以用taskset -pc $(pidof myapp)验证。这种方式的好处是配置随服务声明式管理，机器迁移或重装时只需拷贝unit文件，不依赖额外的启动脚本。
此外，systemd还提供了更现代的AllowedCPUs指令，配合slice机制可以对整组服务做统一的核心划分，例如把数据库服务和Web服务隔离到不同核心集合，避免互相干扰。与CPUAffinity作用于单个服务的粒度不同，slice级别的配置适合做系统级的资源隔离规划。
还有一种思路是使用numactl --physcpubind启动服务，它除了绑定核心，还能同时控制内存分配节点，对于NUMA服务器上的数据库类应用往往比单纯绑核效果更好。
绑定策略的适用场景与常见误区
绑定核心并非万能优化，理解它什么时候有效很重要。最典型的受益场景有三类：一是低延迟交易、音视频处理这类对抖动敏感的应用，绑核可以避免线程被迁移后冷缓存重启；二是网络收包场景，配合RSS把中断和软中断处理线程绑到固定核心，可以让数据通路完全命中同一缓存域；三是多进程共享大量数据的场景，把它们绑到共享L3缓存的核心组内，缓存命中率会显著提升。
反过来，以下几种情况盲目绑核反而有害。第一，如果绑定后核心上还有其他高负载进程在跑，线程只能排队等待，延迟不降反升，绑定前应该用isolcpus内核参数或cgroup把核心先隔离出来。第二，对于负载不均衡的线程组，过度绑定会导致部分核心满载而其他核心空闲，调度器失去调度的灵活性。第三，在开启超线程的机器上，0号和1号核心很可能是同一物理核的两个逻辑核，绑到这两个核心上等于共享执行单元，性能可能不如分开绑定。
排查绑核效果时，perf stat的缓存缺失率和上下文切换次数是最直观的指标，绑定前后对比这两个数字，基本能判断策略是否有效。也可以用pidstat -t -p <pid> 1观察每个线程实际运行的核心，确认绑定生效且没有发生意外迁移。
总结来说，Fedora上实现CPU亲和性绑定的路径很清晰：临时任务用taskset，程序内精细控制用sched_setaffinity系列接口，常驻服务交给systemd配置。真正决定效果的是对应用负载特征和硬件拓扑的理解，绑核只是工具，先测量再优化，才能让每一颗核心都用在刀刃上。