Linux 下应使用 pthread_setaffinity_np 绑定线程到指定 CPU 核心，调用前必须用 CPU_ZERO 初始化 cpu_set_t，核号从 0 开始且需检查返回值与 errno；Windows 应用 SetThreadAffinityMask，其掩码非简单左移。
直接绑定线程到指定 CPU 核心，pthread_setaffinity_np 是 Linux 下最可靠的方式；Windows 必须用 SetThreadAffinityMask；C++26 的 std::this_thread::set_affinity 尚未落地，当前生产环境别依赖。
Linux 下用 pthread_setaffinity_np 绑定线程必须初始化 cpu_set_t
不初始化就调用 pthread_setaffinity_np，行为未定义——常见现象是调用返回 0 却没生效，或直接失败返回 EINVAL。
-
CPU_ZERO(&cpuset)必须放在CPU_SET之前，否则残留位导致意外绑定多个核甚至非法核号 - 核号从 0 开始，4 核机器合法值是 0–3；设成 4 会返回
EINVAL -
sizeof(cpuset)不能写成sizeof(cpu_set_t)：前者是运行时实际位图大小，后者在不同系统可能固定为 128 字节，但 CPU 数超限时会截断 - 调用后应检查返回值，并在失败时读
errno（如ENODEV表示目标核已离线）
示例：绑到 CPU 1 和 3：
cpu_set_t set;
CPU_ZERO(&set);
CPU_SET(1, &set);
CPU_SET(3, &set);
int ret = pthread_setaffinity_np(pthread_self(), sizeof(set), &set);
if (ret != 0) {
// 处理 errno
}
Windows 下 SetThreadAffinityMask 的掩码不是简单左移
SetThreadAffinityMask 看似只要 1ULL 就行，但实际要先与进程允许的掩码做交集，否则可能静默失败。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须先调用
GetProcessAffinityMask获取进程级可用掩码，再用&判断目标位是否有效 - 返回值是旧掩码，不是成功标志；失败时返回 0，但旧掩码也可能为 0，所以必须检查
GetLastError()是否等于ERROR_INVALID_PARAMETER - 掩码第 n 位对应逻辑处理器编号 n，但该编号不等于物理核序号（超线程下 CPU 0 和 CPU 4 可能共享 L1 cache）
- 调用前需确保当前线程句柄有效，且进程拥有
SE_INCREASE_QUOTA_NAME权限，否则失败无提示
示例：安全绑到逻辑核 2：
DWORD_PTR process_mask, system_mask;
if (!GetProcessAffinityMask(GetCurrentProcess(), &process_mask, &system_mask)) return;
DWORD_PTR target = 1ULL << 2;
if ((target & process_mask) == 0) return; // 不在进程允许范围内
DWORD_PTR old = SetThreadAffinityMask(GetCurrentThread(), target);
if (old == 0 && GetLastError() == ERROR_INVALID_PARAMETER) {
// 绑定失败
}
macOS 和嵌入式 Linux 不支持 pthread_setaffinity_np
看似加 #ifdef __linux__ 就能跨平台，但 macOS 根本没有 pthread_setaffinity_np 符号，链接直接报错；musl libc（如 Alpine）也不提供该函数。
- 运行时检测比编译期判断更稳妥：Linux 用
dlsym(RTLD_DEFAULT, "pthread_setaffinity_np")，Windows 用GetProcAddress(GetModuleHandleA("kernel32.dll"), "SetThreadAffinityMask") - 检测失败时不要 abort，记录 warning 并退化为无绑定逻辑——很多场景绑核反而降低性能
- macOS 只能用
thread_policy_set（Mach API），但仅对 real-time 线程有效，普通线程调用无效
绑核后性能下降的三个隐藏原因
绑核不是银弹，很多“优化”实则引入新瓶颈。
- 绑到被其他高负载进程占用的核上，变成争抢而非独占
- 绑到超线程对称逻辑核（如 CPU 0/CPU 4），共享执行单元和缓存，隔离性差
- NUMA 架构下绑到远端内存节点对应的 CPU，访存延迟翻倍——此时应优先绑定到本地内存节点的核
真正需要绑核的场景很窄：低延迟服务、实时音频处理、确定性计算任务。普通后台线程或 IO 密集型任务，交给调度器更稳。
