runtime.NumCPU() 返回逻辑CPU数（含超线程），非物理核心数；用于并发控制易高估真实并行能力，CPU密集型任务中可能因争抢物理核而降低吞吐。
runtime.NumCPU 返回的是逻辑 CPU 数，不是物理核心数
它读取的是操作系统报告的可调度线程数（即 sysctl hw.ncpu 在 macOS、/proc/cpuinfo 中 processor 行数在 Linux），包含超线程带来的虚拟核。比如 8 核 16 线程的 CPU，runtime.NumCPU() 返回 16，而非 8。
这意味着：用它做 goroutine 并发度上限、worker pool 初始化数量时，容易高估真实并行能力——尤其在 CPU 密集型任务中，线程争抢物理核心反而降低吞吐。
- 压测时若按
runtime.NumCPU()启动等量 CPU 绑定 worker，实际可能因超线程共享执行单元而出现缓存抖动、TLB 冲突 - 物理核心数需手动查：
lscpu | grep "Core(s) per socket"（Linux）或sysctl -n hw.physicalcpu（macOS） - Go 1.21+ 可配合
runtime.LockOSThread()+syscall.SchedSetaffinity()做绑定，但runtime.NumCPU()本身不参与绑定逻辑
绑定 OS 线程到指定 CPU 核心必须用 syscall.SchedSetaffinity
Go 没有内置的“绑定到第 N 核”高级 API，runtime.GOMAXPROCS() 控制的是 P 的数量，和 OS 线程绑定无关；goroutine 调度完全由 Go runtime 管理，无法直接指定运行在哪颗物理核上。
真要绑定，得在 goroutine 中锁定 OS 线程，再调用系统调用设置 CPU 亲和性：
立即学习“go语言免费学习笔记（深入）”；
import "syscall"
func bindToCore(coreID int) error {
var cpuSet syscall.CPUSet
cpuSet.Set(coreID)
return syscall.SchedSetaffinity(0, &cpuSet) // 0 表示当前线程
}- 必须先调用
runtime.LockOSThread()，否则 goroutine 可能被 runtime 迁移到其他 M 上，绑定失效 -
coreID从0开始，最大值为runtime.NumCPU() - 1，超出会返回EINVAL - 绑定后该 OS 线程只能在指定核上运行，但 Go runtime 仍可能把其他 goroutine 调度到同一 M —— 所以通常需搭配独立的、长期存活的 goroutine 使用
性能压测中盲目绑定反而导致 QPS 下降
常见误区是“绑得越细越好”，比如为每个 goroutine 单独绑定一个核。这在多数场景下适得其反：
- Go 的网络轮询器（netpoll）和 timer 驱动依赖全局 M，强制绑定会干扰 runtime 内部协作机制
- 如果压测 client 和 server 运行在同一台机器，且都绑定核心，极易发生核间竞争（如 client 占满 core0，server 却被调度到 core0，实际没隔离）
- NUMA 架构下，未考虑内存本地性（local memory node）的绑定会导致远端内存访问延迟飙升，
numactl --cpunodebind=0 --membind=0 ./server比纯 syscall 绑定更稳妥 - 建议压测前先用
perf stat -e cycles,instructions,cache-misses对比绑定/不绑定下的硬件事件差异，而非只看 QPS
runtime.LockOSThread 是“单次锁定”，不是“永久绑定”
它只保证当前 goroutine 与当前 M 绑定，一旦该 goroutine 阻塞（如 sysread、channel receive、time.Sleep），M 会被释放，goroutine 唤醒后可能落在别的 M 上 —— 此时绑定已丢失。
- 若需全程绑定，必须让 goroutine 保持非阻塞状态，或在每次可能阻塞前重新调用
runtime.LockOSThread()（不推荐，易出错） - 更可靠的做法是：启动一个不退出的 goroutine，在循环内做
LockOSThread()+SchedSetaffinity()+ 实际工作，避免调度器介入 - 注意：多次调用
LockOSThread()没问题，但UnlockOSThread()必须成对，否则 goroutine 退出时 panic
真正难的不是调几个函数，而是搞清你压的到底是 CPU 计算、内存带宽、还是 L3 缓存一致性 —— 这些决定了该绑核、绑 NUMA node，还是干脆不绑。
