C++ 实现基于 CPU 核心绑定的高性能多线程任务分发器 _ 源码【源码】

直接绑定线程到特定 CPU 核心——这个操作能大幅减少上下文切换和缓存抖动，理论上谁都知道。但真正落地的时候，问题就来了：std::thread 本身根本不提供跨平台的绑定能力。你必须依赖操作系统原生 API，在 Linux 下是 pthread_setaffinity_np，在 Windows 下是 SetThreadAffinityMask。而且关键在于：必须在 std::thread 启动后、执行前立即设置，否则绑了也白绑。

Linux 下的绑定实践：pthread_setaffinity_np 的硬核用法

很多人踩的第一个坑，就是想当然地对 std::thread::native_handle() 直接调用 pthread_setaffinity_np。行不通——这个句柄的类型没有标准化，实际必须先转成 pthread_t，再去操作 CPU 亲和性掩码 cpu_set_t。

这里的操作步骤其实很清晰，但细节决定成败：

• CPU_SET 的第二个参数必须是已经通过 CPU_ZERO 清空过的 cpu_set_t，否则结果未定义。
• 调用 pthread_setaffinity_np 这件事，必须在线程启动后、首次执行用户代码前搞定。最稳妥的做法是：在 std::thread 构造时的 lambda 里，第一行就干这个。
• 如果目标核心压根不存在——比如系统只有 4 个核心，你却偏要绑 8 号核——函数会返回 EINVAL。所以，建议先通过 sched_getaffinity 摸清可用核心的上限。

一段典型的正确代码长这样：

auto worker = [core_id](TaskQueue& q) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);
    pthread_setaffinity_np(pthread_self(), sizeof(cpuset), &cpuset);
    while (auto task = q.pop()) {
        task();
    }
};
std::thread t(worker, std::ref(queue));

Windows 下的隐蔽陷阱：SetThreadAffinityMask

Windows 这边的坑，跟 Linux 不是一个路子。它的亲和性掩码是位掩码，不是核索引。比如你想绑定到第 2 号核心（也就是 CPU#1，技术圈从 0 开始计数），得传 1ULL << 1，而不是直接传 1。

更致命的问题在于：如果进程被系统限制了可用处理器组（Processor Group），直接调用 SetThreadAffinityMask 可能静默失败——返回 0，而且 GetLastError 还不一定给你报错。

几个必须记住的原则：

• 动手绑定之前，务必调用 GetProcessAffinityMask，确认当前进程允许使用的掩码范围。
• 遇到超过 64 核心的机器，就必须配合 SetThreadGroupAffinity 来跨组操作，单靠 SetThreadAffinityMask 是不够的。
• 用 MSVC 编译时，记得把 _WIN32_WINNT 定义为 0x0601 或更高（对应 Windows 7+），否则 SetThreadAffinityMask 的声明你都看不见。

为什么不在构造时绑定，非要等线程跑起来再说

很多人疑惑：既然 std::thread 构造的时候就指定了线程函数，为什么不在那个时候就绑定核心？原因很直白：std::thread 的构造函数仅仅是“安排”线程启动，而它的内部线程 ID 和 OS 级别的线程句柄（pthread_t 或 HANDLE），要等到线程真正被调度运行的那一刻才会完全就绪。

如果在构造之后、join 之前的任意时间点去调用绑定 API，都会碰到竞态风险——线程可能已经开始执行了，甚至已经跑完退出了。这时候绑定，要么失败，要么绑错了对象。

唯一的“安全窗口”就是在线程函数的入口处，用 pthread_self() 或者 GetCurrentThread() 获取当前上下文句柄，然后立刻绑定。千万不要试图在主线程里保存 std::thread::native_handle() 然后延后绑定——在某些标准库实现里，这个句柄只在线程运行期间有效。

如果需要统一管理绑定逻辑，可以考虑封装一个 BoundThread 类，在它的构造函数里启动线程，并在 lambda 中立刻执行绑定。

被很多人忽略的 NUMA 意识问题

单纯按核心编号来绑定（比如 core 0–3 分别对应线程 A–D），在 NUMA 架构下很容易翻车。举个例子：CPU socket 0 上跑的线程，如果频繁访问 socket 1 的内存，延迟直接翻倍。这时候，性能优化的关键就不再是“绑哪个核心”，而是“绑哪个 NUMA 节点”。

所以，在绑定核心之前，真正值得做的事情是：

• 在 Linux 下用 numactl --hardware 查看节点拓扑，然后通过 libnuma 的 numa_node_of_cpu 把核心映射到对应的节点。
• 在 Windows 下调用 GetNumaNodeNumberFromHandle，配合 GetNumaA vailableMemoryNode 来判断本地内存的容量。
• 更进一步，任务队列本身最好也按 NUMA 节点分区——设计成 per-node task queue，避免跨节点争用锁。

核心绑定这件事，说到底只是一个起点。真正的性能瓶颈，往往藏在内存访问路径里。如果不看 NUMA 拓扑就硬绑核心，多线程的吞吐量不升反降，才是真的尴尬。