在cpu资源饱和时，线程数多的进程确实会分得更多cpu时间；但在常规负载下，线程数量并不直接决定计算吞吐量，关键在于调度效率与资源匹配度。
在cpu资源饱和时，线程数多的进程确实会分得更多cpu时间；但在常规负载下，线程数量并不直接决定计算吞吐量，关键在于调度效率与资源匹配度。
现代操作系统（如Linux）采用基于时间片的抢占式调度，其基本调度单位是线程（task_struct），而非进程。这意味着：当系统中存在60个就绪态计算型线程（无I/O阻塞），且CPU核心数固定（例如8核），内核调度器会轮询分配CPU时间片给这60个线程——每个线程理论上获得均等的调度机会。因此，在长期统计意义上：
- 进程C（30线程）将获得约 50% 的总CPU时间（30/60）；
- 进程B（20线程）获得约 33.3%；
- 进程A（10线程）仅获约 16.7%。
✅ 这一现象真实存在，也正说明：单纯增加线程数，确实在争抢式场景下能“抢占”更多CPU资源——这正是你直觉中“不公平”的根源。恶意或低效程序可通过创建海量空转线程（thread bombing）加剧系统负载，影响其他进程，这也是为何生产环境需配合cgroups、CPU quotas或nice优先级进行资源治理。
⚠️ 但必须强调：这种“线程越多越快”的优势仅在CPU持续满载（overloaded）时成立。一旦系统有空闲周期（即总就绪工作量
这正是Go运行时调度模型的设计出发点。Go不依赖OS线程一一对应goroutine，而是采用 M:N调度器（G-P-M模型）：
-
G（Goroutine）：轻量协程（初始栈仅2KB，可动态扩容）； -
P（Processor）：逻辑处理器，数量默认=GOMAXPROCS（通常等于CPU核心数）； -
M（Machine）：OS线程，数量按需伸缩（通常 ≤P数量）。
// 示例：即使启动30个goroutine，Go默认也只使用8个OS线程（假设8核）
func main() {
runtime.GOMAXPROCS(8) // 显式设置，也可省略（默认即CPU数）
for i := 0; i < 30; i++ {
go func(id int) {
// 纯计算任务，无阻塞
var sum uint64
for j := 0; j < 1e9; j++ {
sum += uint64(j)
}
fmt.Printf("Goroutine %d done\n", id)
}(i)
}
time.Sleep(time.Second * 2)
}✅ 在典型负载下（非满载），Go通过P绑定CPU核心、G在P本地队列高效复用、M按需唤醒/休眠，实现了：
- 低调度开销：避免OS级线程频繁切换；
- 高资源利用率：30个goroutine可被8个P平滑调度，效果接近8个精心编排的OS线程；
- 公平性保障：Go调度器内置公平轮转与工作窃取（work-stealing），防止某P饥饿。
因此，Go设定GOMAXPROCS = CPU核心数并非为了“压制线程数”，而是在绝大多数场景下，让逻辑并发规模（goroutines）与物理并行能力（CPU cores）达成最优匹配——既避免过度调度，又充分榨干硬件潜力。
? 总结建议：
- ❌ 不要为“抢CPU”盲目增线程——这是反模式，应交由资源隔离机制（如cgroup v2、Kubernetes CPU limits）约束；
- ✅ 关注实际瓶颈：用
perf top、/proc/PID/status或go tool pprof分析是CPU-bound、memory-bound还是调度等待； - ✅ Go开发中，优先使用goroutine + channel构建并发逻辑，让运行时自动优化底层线程调度；仅在极少数需绑定特定核心（如实时计算）时，才显式调优
GOMAXPROCS或使用runtime.LockOSThread()。
