现象
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 有），可以救回
- ❌ 没有显式重绑机制的：librdkafka 的 rdk:main / rdk:bro+ / 每个 broker 的 worker、ZMQ context
内部 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：
- 修复前：0x1（仅 CPU 0）
- 修复后：0xffffffff...（所有核）
直接 taskset -p $tid 就能看出来。
教训
1. pthread_setaffinity_np 是有传染性的——绑了父线程，后续 spawn出来的所有线程都被传染，包括你看不见的第三方库内部线程。
2. 如果一定要绑 main，要么在所有子线程创建之后再绑，要么用 pthread_attr_setaffinity_np
给每个具体线程显式设亲和性。前者有种顺序依赖、后者要求你能控制每个线程的创建——第三方库做不到。
3. 绑核默认值不要用 0。CPU 0 是最容易被系统中断（IRQ 处理、softirq、内核 worker）打扰的核。"找不到配置就绑 0" 是双重坑：第一坑是上面的传染性，第二坑是绑了一个最忙的核。
4. 观测手段：top -H 看每个线程的 CPU% 和 R/D/S 状态，加上 taskset -p 查 affinitymask，是最快定位类似问题的组合。top 总 CPU 看着只有 100%、但有 12 个线程都活着——这种"线程多但
CPU 上不去"的反直觉模式就是亲和性继承在作祟。
