pthread亲和性继承的一个坑：main绑核让整个进程退化到单核

现象

C++ 多线程进程 qfactor（19 万行/分钟的高频股票因子计算），配 work_thread_nums=8，应该用 8 个

build 线程并行处理 8 个 partition 的数据。但实测 CPU 只跑满 1 个核（101%），per-factor cycle

耗时 23 秒；同一份代码在另一个分支上 CPU 用满 8.3 核（832%），cycle 只要 2 秒。12倍速度差，但代码逻辑、编译选项、ylfeature 子模块全部完全相同。

排查过程

按嫌疑度走过的死胡同：

根因

// apps/qfactor/main.cc:147（quick 上有）

if (config->getOtherCpuID() >= 0) {

utility::bindCurrentThreadToCpu(config->getOtherCpuID(), "main");

} else {

utility::bindCurrentThreadToCpu(0, "main"); // ← 默认 fallback 到 CPU 0

}

m3 分支没这段。

Linux pthread_create 默认继承父线程的 CPU 亲和性（man pthread_create）。一旦 main 被

pthread_setaffinity_np 绑到单核，所有从 main 派生的子线程出生时都自动只能跑那个核：

✅ 显式 bindThreadToCpu 重绑的：buildThreads[i]、sendThread、checkMasterThread------pthread_create

后立刻被重绑到 config 指定核（如果 config 有），可以救回

内部 epoll 线程、Boost.Log async sink 后台线程、Redis hiredis subscriber、OceanView

心跳------全部继承 main 的单核亲和性，再也回不来

如果 config 没配 other_cpu_id（很多场景默认不配），fallback 把 main 绑到 CPU0，整个进程的所有线程被锁在 CPU 0 上 time-slice 共享。12 个线程挤一核，每个线程拿到 ~7%CPU，总和 100%。

验证数据

修 main.cc，把那 5 行删掉，重编译重跑：

CPU build 线程 cycle 耗时

quick 修复前 101% 7-13% × 12 23.4s

quick 修复后 832% 87-99% × 11 2.0s ← 12× 提速

m3 对照 893% 99-100% × 11 2.0s

每只线程的 affinity mask：

直接 taskset -p $tid 就能看出来。

教训

给每个具体线程显式设亲和性。前者有种顺序依赖、后者要求你能控制每个线程的创建------第三方库做不到。

绑核默认值不要用 0。CPU 0 是最容易被系统中断（IRQ 处理、softirq、内核 worker）打扰的核。"找不到配置就绑 0" 是双重坑：第一坑是上面的传染性，第二坑是绑了一个最忙的核。
观测手段：top -H 看每个线程的 CPU% 和 R/D/S 状态，加上 taskset -p 查 affinitymask，是最快定位类似问题的组合。top 总 CPU 看着只有 100%、但有 12 个线程都活着------这种"线程多但

CPU 上不去"的反直觉模式就是亲和性继承在作祟。