CPU热插拔与线程绑核：从强制迁移到亲和性失效的全解析

半夜两点被值班电话叫起来，说某台服务器上有个CPU核心温度异常，得马上把那一核给隔离掉。业务团队在旁边急得不行，因为他们的核心线程全部绑在了那颗核上，谁也不知道把CPU offline之后线程会不会直接崩。这个场景我相信不少做性能优化或者基础设施的同学都遇到过，平时大家聊绑核聊得头头是道，但一碰到“CPU热插拔”这种维护操作，立刻心里没底。CPU offline/online本身不复杂，复杂的是它和线程绑核属性之间的相互作用。我花了两天时间把内核行为、调度器逻辑和用户态表现完整捋了一遍，又写了测试程序逐一验证，这篇就把所有细节和坑位讲清楚。

1. 问题从哪来：CPU热插拔与线程绑核的碰撞

1.1 谁会在生产环境用CPU offline/online

很多人以为CPU热插拔只是服务器硬件维护才用的功能，其实在纯软件层面，把某个逻辑核心offline的场景非常多。最常见的是硬件告警隔离，像ECC错误过多、温度阈值告警这类情况，运维会先通过sysfs接口把对应核心摘掉，再安排后续硬件更换。其次是在线调优，比如某些云厂商的宿主机在业务低峰期会把部分cores offline掉来省电，或者给同一物理机上的其他虚拟机腾资源。还有一类是软件兼容性测试，比如验证操作系统在CPU数量动态变化时是否稳定。

操作方式本身很简单，root权限下往sysfs节点写个0或1就行：

# 查看所有核心的在线状态 cat /sys/devices/system/cpu/online # 将cpu3离线 echo 0 > /sys/devices/system/cpu/cpu3/online # 重新上线 echo 1 > /sys/devices/system/cpu/cpu3/online

但这条命令背后隐藏的问题相当深。一个正在运行的内核线程、用户态线程，或者其他绑定了这个CPU亲和性的任务，在内核把CPU摘掉的瞬间，到底会经历什么？是将就着继续在offline的核上跑，还是被强制搬家？搬家之后绑核属性还在不在？我后面会逐一拆解。

1.2 线程绑核的初衷：缓存亲和与性能确定性

线程绑核这件事，做服务端性能优化的同学应该都不陌生。通过sched_setaffinity或pthread_setaffinity_np把线程固定到某个CPU上，核心目的是利用CPU缓存的局部性。线程频繁访问的数据如果一直留在L1/L2 cache里，命中的话能省下几十个周期的内存访问延迟。在NUMA架构下这种收益更明显，本地内存访问和远端内存访问的延迟差可以达到两倍以上。

我见过很多高吞吐中间件的绑核配置，比如DPDK的lcore、Nginx的worker进程绑定、MySQL的线程组绑定，目的都是为了让核心线程独占CPU，减少调度器带来的上下文切换和runqueue迁移开销。此外还有一类特殊场景：实时线程通过绑定获得确定性调度延迟，避免被调度器丢到某个负载很重的核上排队。

但绑核从来不是没有代价的，最大的代价就是灵活性变差。系统里只要有一颗物理核心硬件故障，或者需要关机维修，绑在上面的业务线程就变成“钉子户”，处理起来非常棘手。

1.3 为什么这个问题容易被忽视

聊到CPU热插拔时，大多数人想的是内存条、PCIe设备那种物理热插拔，很少有人会主动去思考逻辑CPU的online/offline对调度器产生什么影响。而聊到线程绑核时，大家又默认绑定关系是“铁打的营盘”，只要不主动改affinity，线程就会一直待在指定核上。

这两个认知盲区一叠加，就形成了生产环境的雷区。更糟糕的是，内核在CPU offline时处理绑核线程的路径非常隐蔽，日常监控根本看不到，只有真正触发时才会暴露问题。所以我建议所有做基础架构、SRE、性能优化的同学把这个问题彻底搞清楚，别等到线上事故了再临时抱佛脚。

2. 绑核到底绑的是什么：亲和性属性的本质

2.1 用户态绑核API的调用链

在Linux下，绑核操作有两个常用入口。一个是直接调用系统调用sched_setaffinity(2)，另一个是POSIX线程库的pthread_setaffinity_np(3)。从内核视角看，这两个入口最终走的是同一条路径，即__sched_setaffinity()，只是参数格式上略有区别。sched_setaffinity接收进程PID，pthread_setaffinity_np接收线程ID（在Linux中即TID），但最终都是操作对应task_struct的调度相关字段。

先看一个最基础的绑核示例，后面实验也会用到这套API：

#define _GNU_SOURCE #include <sched.h> #include <stdio.h> #include <pthread.h> void bind_cpu(int cpu) { cpu_set_t set; CPU_ZERO(&set); CPU_SET(cpu, &set); if (pthread_setaffinity_np(pthread_self(), sizeof(set), &set) != 0) { perror("pthread_setaffinity_np"); } }

这段代码里有个关键点：CPU_SET(cpu, &set)实际上是往一个位图里置位，这个位图的每一位代表一个逻辑CPU编号。内核拿到这个位图后，会和线程当前的cpuset限制做一次交集运算，最后真正生效的是两者重叠的部分。很多人在容器里绑核失败，就是因为漏掉了cpuset这层过滤。

2.2 affinity mask在内核里的存在形式

每个线程的task_struct里保存着两个关键字段：cpus_mask和user_cpus_ptr。其中cpus_mask是内核调度器实际使用的affinity掩码，user_cpus_ptr则是用户通过sched_setaffinity设置的原始掩码。为什么要存两份？因为内核允许cpuset cgroup在运行时修改可用CPU集合，如果直接把用户的mask覆盖掉，恢复时就丢失原始数据了。

调度器在每次挑选运行CPU时，会先看task->cpus_mask，从中选出合适的CPU。这个筛选过程有多层：首先是cpuset控制器产生的cpu_allowed，然后是用户显式设置的affinity mask，两者取交集后得到tsk_cpus_allowed。换句话说，即使你绑定了cpu0，如果cpuset里没有cpu0，这个绑定也不会生效。

2.3 绑核属性与CPU在线状态的隐藏关系

这里有一个非常关键的细节：affinity mask里包含一个已经offline的CPU，是完全合法的。也就是说，你可以在cpu3 offline之后，仍然调用sched_setaffinity把线程绑定到cpu3上，这个系统调用不会报错，只是调度器永远不会让线程真正运行到cpu3上。

反过来，如果线程在cpu3 offline之前就已经绑定了cpu3，内核在CPU下线时的行为就不是简单置一个标志位了，它会主动介入并改写线程的affinity mask。我见过很多人对这个行为完全没概念，觉得“绑定的核掉了，任务要么卡死要么崩”，实际情况比这复杂得多。为了把这个过程讲清楚，我们得先看调度器是怎么维护CPU状态的。

3. CPU offline时内核如何处理绑核线程

3.1 热插拔流程的完整路径

Linux内核的CPU热插拔实现经过多次重构，现在使用cpuhp状态机来管理。当用户往sysfs写0时，会触发device_offline()，进而执行cpuhp_down_callbacks中的一系列回调函数。核心流程大致是：先通知各个子系统准备下线，然后通过stop_machine机制把该CPU上的所有活动任务停掉，执行__cpu_disable，最后将该CPU从各种全局状态掩码中摘除。

这里需要观察到的是：整个过程有三个关键掩码在同步变化。cpu_online_mask表示当前可以运行任务的CPU集合；cpu_active_mask表示调度器认为活跃的CPU集合；cpu_present_mask和cpu_possible_mask则代表系统硬件上存在和理论上可能存在的CPU集合。一般情况下online和active是重合的，offline时这两个掩码都会把目标CPU移除。

3.2 active_mask才是调度器的“生死簿”

很多人以为调度器只看cpu_online_mask，其实不完全对。负载均衡和任务调度实际参考的是cpu_active_mask，这个掩码的维护比online_mask更精细。在cpu offline流程中，内核会先调用sched_cpu_deactivate()，将目标CPU从cpu_active_mask中移除。这一步的意义在于：调度器从此刻起不会再主动把新任务放到这个CPU上。

但问题来了，已经绑定在这个CPU上、并且还在运行队列里的任务怎么办？内核的做法是强制迁移。触发迁移的机制是每个CPU都有一个migration内核线程，当CPU进入下线流程时，迁移线程会被唤醒，把当前CPU运行队列里的所有可运行任务逐一迁到其他CPU上。

3.3 绑定线程的强制迁移机制拆解

绑定了cpu3的线程在cpu3被offline时，会经历这样一个过程：

当调度器把cpu3从cpu_active_mask移除后，并不代表cpu3上立刻没有任务。此时cpu3的rq（runqueue）上可能还躺着若干个绑定了该核心的任务。内核的migration_cpu_stop机制会被触发，该CPU上的migration线程会把rq中的任务重新加入调度。每个被迁移的任务会被重新计算affinity，内核会临时将任务的cpus_mask调整为当前可用的online CPU集合。

这个调整很值得注意：它不会简单地保留原mask再跳过offline的CPU，而是直接把offline的CPU从mask里移除。所以如果你原本绑定的是cpu3，offline后线程被迁移到cpu0，那么此时线程的实际affinity mask就不再包含cpu3了。等你把cpu3重新online回来，线程也不会自动恢复对cpu3的绑定——它在内核眼中已经是另一个affinity集合的任务了。

3.4 为什么恢复online后线程不会自动迁回

这个问题我在实验里反复确认过：cpu3重新online后，之前绑在cpu3上的线程依然跑在其他核上，affinity mask里也没有cpu3。原因很简单——内核的设计哲学是“重启后不恢复现场”。线程的affinity mask在迁移时已经被改写成新的online CPU集合，内核没有任何机制记录“这个任务原本应该在哪颗核上”。避免自动回迁是合理的安全决策：如果业务代码对CPU环境有依赖，贸然迁回一个刚恢复的核，可能又触发一次Cache冷启动，反而影响性能。

所以这里给业务团队的第一条建议就是：不要假设绑核关系是永久的，任何一次CPU offline操作都可能改写你的affinity mask。不要让业务逻辑强依赖“我一定在某颗核上运行”，系统维护性会变得非常脆弱。

4. 动手验证：一个完整的绑定线程热插拔实验

4.1 实验环境与测试程序

纸上谈兵没意思，我用一台四核虚拟机做了完整验证。系统是Ubuntu 22.04，内核版本5.15，CPU编号从0到3。测试程序逻辑很简单：创建4个worker线程，每个线程通过命令行参数指定绑定到不同的CPU，然后每秒打印一次当前运行CPU和affinity mask的位数。

#define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <pthread.h> #include <sched.h> #include <unistd.h> typedef struct { int id; int bind_cpu; } worker_ctx_t; void print_affinity(int id) { cpu_set_t set; CPU_ZERO(&set); if (sched_getaffinity(0, sizeof(set), &set) != 0) { perror("sched_getaffinity"); return; } int count = 0; for (int i = 0; i < CPU_SETSIZE; i++) { if (CPU_ISSET(i, &set)) { count++; } } printf("worker[%d] running_on_cpu=%d affinity_mask_cpus=%d\n", id, sched_getcpu(), count); fflush(stdout); } void *worker_func(void *arg) { worker_ctx_t *ctx = (worker_ctx_t *)arg; cpu_set_t set; CPU_ZERO(&set); CPU_SET(ctx->bind_cpu, &set); if (pthread_setaffinity_np(pthread_self(), sizeof(set), &set) != 0) { perror("pthread_setaffinity_np"); } while (1) { print_affinity(ctx->id); sleep(1); } return NULL; } int main(int argc, char *argv[]) { if (argc < 2) { fprintf(stderr, "Usage: %s <cpu0> <cpu1> <cpu2> <cpu3>\n", argv[0]); return 1; } pthread_t threads[4]; worker_ctx_t ctxs[4]; for (int i = 0; i < 4; i++) { ctxs[i].id = i; ctxs[i].bind_cpu = atoi(argv[i + 1]); pthread_create(&threads[i], NULL, worker_func, &ctxs[i]); } for (int i = 0; i < 4; i++) { pthread_join(threads[i], NULL); } return 0; }

编译命令：

gcc -o affinity_test affinity_test.c -lpthread

4.2 第一步：启动任务并观察初始状态

用root权限启动程序，把4个线程分别绑定到cpu0、cpu1、cpu2、cpu3：

sudo ./affinity_test 0 1 2 3

初始输出如下：

worker[0] running_on_cpu=0 affinity_mask_cpus=1 worker[1] running_on_cpu=1 affinity_mask_cpus=1 worker[2] running_on_cpu=2 affinity_mask_cpus=1 worker[3] running_on_cpu=3 affinity_mask_cpus=1

每个线程都如预期跑在绑定的核上，affinity mask只有1个CPU。这里有个小提醒：程序里打印的是affinity_mask_cpus=1，指的是mask里只有1个CPU在位，不是CPU编号。

4.3 第二步：下线指定CPU，观察线程与affinity变化

保持程序运行，另开一个终端，执行以下命令把cpu3下线：

sudo sh -c 'echo 0 > /sys/devices/system/cpu/cpu3/online'

执行后回到程序终端，观察worker[3]的输出变化：

worker[3] running_on_cpu=0 affinity_mask_cpus=3

worker[3]的编号保持不变，但运行CPU已经变成了cpu0，affinity mask也变成了3个CPU。这说明内核没有让线程卡死或崩溃，而是把它强制迁移到了其他online核心上，同时改写了它的affinity mask。

这里就出现了一个值得注意的现象：worker[3]原本绑定cpu3，现在被迁移到cpu0，而且affinity mask变成3个CPU。这意味着它不是被“临时寄放”到cpu0，而是被彻底解除了对cpu3的绑定。

4.4 第三步：恢复CPU，观察是否自动回迁

再把cpu3重新上线：

sudo sh -c 'echo 1 > /sys/devices/system/cpu/cpu3/online'

等几秒，看程序的输出。

worker[3] running_on_cpu=0 affinity_mask_cpus=4

注意，这里affinity_mask变成了4，因为cpu3重新进入了online集合，所以mask里出现了第4个CPU，但worker[3]依然运行在cpu0上，并没有自动回到cpu3。这就印证了前面说的结论：内核只会把cpu3重新加入可用集合，不会把之前绑定它的线程迁回去。

4.5 实验结论汇总

把实验结果整理成一张速查表：

这张表基本回答了我刚开始被问到的核心问题：cpu offline/online时，线程不会崩，绑定关系一定会被改写，且不会自动恢复。

5. 线上场景的典型问题与排查手法

5.1 线程“卡死”或延迟飙升的真正原因

有人会说，实验里线程不是安然无恙吗？为什么生产环境里一offline CPU，业务立刻出现卡顿。这背后的原因往往不在“线程是否还能运行”，而在迁移过程本身。

第一，Cache冷启动。线程原来在cpu3上跑得好好的，L1/L2里全是热数据，突然迁移到cpu0，缓存全部失效，接下来一段时间内每次内存访问都可能miss，延迟暴增。对于延迟敏感型业务，这个影响远比线程不能运行严重得多。

第二，迁移发生在stop_machine阶段，全局中断被关掉的时间窗口内，所有核都在等待迁移完成。如果迁移的任务数量巨大，这个窗口可能被拉长到毫秒级，整个系统的实时性都会受到影响。

5.2 迁移后负载不均衡

另一个常见问题是CPU offline后，原本绑在它上面的任务“溢出”到了其他核心，导致负载失衡。因为任务迁移目的地是由调度器决定的，它一般优先选择当前rq负载最低的CPU，但如果迁出任务很多、目标CPU各自负载又高，就会出现某一颗核瞬时打满、其他核空闲的情况。

碰到这种情况，我建议不要慌着做负载均衡，先观察几秒。内核的周期性负载均衡会把任务拉平，只是需要时间。如果业务不能忍受这个过渡期，就得在offline前手动把绑定这些核心的业务线程重新分配好。

5.3 容器与cpuset叠加时的深水区

容器场景下的问题更隐蔽。如果线程跑在docker容器里，并且容器指定了cpuset，那么线程的affinity mask实际上是cpuset限制后剩下的CPU集合。当你offline掉容器cpuset中唯一的CPU时，线程会怎样？

答案是：线程不会被迁移到容器外的CPU上，因为cpuset的边界严格限制了线程的可运行集合。此时线程会保持“可运行但无法调度”的状态，表现为进程CPU时间几乎为零、响应完全停滞。这比裸机场景危险得多。

排查这类问题时，一定要三层一起查：

# 查看线程的实际affinity taskset -p <tid> # 查看cgroup cpuset限制 cat /sys/fs/cgroup/cpuset/<container_path>/cpuset.cpus.effective # 查看CPU在线状态 cat /sys/devices/system/cpu/online

如果发现cpuset.effective是空的，说明容器内已经没有任何可用CPU，线程卡死就是必然结果。处理办法是调整容器的cpuset配置，加入其他在线CPU，再手动触发线程迁移。

5.4 实时线程与isolcpus特殊场景

如果你用了isolcpus内核参数隔离CPU，或者给实时线程设置了SCHED_FIFO/SCHED_RR调度策略，CPU offline的处理会更复杂。isolcpus隔离出来的CPU默认不参与普通负载均衡，上面的线程通常是业务手动绑上去的，一旦这颗核offline，迁移逻辑和普通核没本质区别，但恢复后隔离属性是保留的，线程却回不去了。

实时线程的问题在于：stop_machine过程本身会引入中断延迟，而实时线程对延迟极敏感。如果实时业务线程绑定的CPU被offline，迁移过程中可能出现一个调度周期内线程完全没有运行的情况，这在工业控制场景下是无法接受的。所以对实时任务，运维规范必须是“先解绑或迁移任务，再下线CPU”，顺序不能反。

6. 给业务代码的防坑建议

6.1 不要硬绑，要软绑

我在设计自己维护的中间件时，定的原则是“软亲和优先”。所谓软亲和，是指用nice、cpuset cgroup这类权重型限制，而不是把线程死死绑在单颗核上。权重型限制允许调度器在极端情况下灵活调整，不会因为某颗核offline就直接改写业务属性。

只有在明确需要独占核心的场景（比如DPDK轮询、实时信号处理），才使用硬绑核。但即便硬绑，也必须配套CPU热插拔的监测机制。你可以通过netlink监听内核uevent事件，当检测到CPU offline时，立即重新设置业务线程的affinity mask到备用CPU集合。

简单监听示例（基于netlink的uevent）：

#include <linux/netlink.h> #include <sys/socket.h> #include <unistd.h> #include <stdio.h> #include <string.h> int watch_cpu_uevent() { int sock = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT); struct sockaddr_nl addr; memset(&addr, 0, sizeof(addr)); addr.nl_family = AF_NETLINK; addr.nl_pid = getpid(); addr.nl_groups = 1; bind(sock, (struct sockaddr *)&addr, sizeof(addr)); char buf[8192]; while (1) { ssize_t len = recv(sock, buf, sizeof(buf), 0); if (len <= 0) continue; buf[len] = '\0'; if (strstr(buf, "cpu") && (strstr(buf, "offline") || strstr(buf, "online"))) { printf("CPU event detected: %s\n", buf); // 在这里调整业务线程的affinity } } return 0; }

6.2 运维侧规范：先解绑，再下线

不管业务代码做得多完善，运维侧的顺序都很关键。强烈建议把“CPU offline操作”纳入变更流程，执行前先检查目标核上是否有业务线程绑定：

# 找出绑定到cpu3上的线程 for tid in $(ls /proc/*/task/ 2>/dev/null | grep -E '^[0-9]+$'); do affinity=$(taskset -pc $tid 2>/dev/null | grep -E 'cpu3' ) if [ -n "$affinity" ]; then echo "tid=$tid: $affinity" fi done

如果发现关键业务线程，先在应用层触发线程重新绑核，确认迁移完成后，再执行echo 0操作。这个顺序可以大幅降低事故概率。

6.3 监控与告警：关注CPU状态变化事件

除了业务侧调整，基础设施监控也要覆盖CPU online/offline事件。/sys/devices/system/cpu/online文件的内容变化、内核日志中的CPU hotplug消息，都值得接入告警。比如执行offline后，内核日志会输出类似以下内容：

kernel: CPU3: offline kernel: smpboot: CPU 3 is now offline

这些日志如果出现在半夜，需要确认是不是有同事在做变更，否则可能是硬件故障触发的自动隔离。建议监控系统直接采集这些事件，配合业务指标（线程延迟、队列积压）做关联分析，能更快定位问题。

6.4 个人经验总结

做底层性能优化这些年，我见过太多因为绑核和热插拔撞车引发的事故。最典型的就是某核心温度告警触发了硬件管理工具自动offline，结果把一台生产数据库的所有查询线程全部摞到几个核上，瞬间出现CPU争抢风暴。事后复盘，根因就是业务代码硬绑核，又不监听CPU状态事件，调度器被迫在几毫秒内迁移大量任务，整个系统的延迟曲线直接起飞。

踩过几次坑之后，我现在的做法很简单：确认要绑定核心的线程，一定是可重绑的——启动时读取配置获取CPU列表，运行时监听CPU状态变化，一旦发现当前绑定核离线或即将离线，立刻执行备选绑定方案。核心设计思想是永远不会把鸡蛋都放在一个篮子里，绑核策略必须允许系统动态调整，同时设置兜底方案。这套思路已经支撑我在多个高负载生产环境里稳定运行了很长时间，分享出来也是希望大家少走弯路。