在cpu资源饱和时，线程数多的进程确实可能获得更高总cpu时间，但这并非系统设计的“公平性缺陷”，而是调度器对可用资源的客观分配；go通过gomaxprocs限制os线程数、配合轻量级goroutine调度，旨在提升单进程内并发效率，而非抢占更多系统资源。
在cpu资源饱和时，线程数多的进程确实可能获得更高总cpu时间，但这并非系统设计的“公平性缺陷”，而是调度器对可用资源的客观分配；go通过gomaxprocs限制os线程数、配合轻量级goroutine调度，旨在提升单进程内并发效率，而非抢占更多系统资源。
现代操作系统（如Linux）采用基于时间片的完全公平调度器（CFS），其核心调度单位是线程（task_struct），而非进程。这意味着：当系统处于CPU过载状态（即就绪态线程总数远超可用逻辑CPU核心数）时，内核会按线程粒度分配CPU时间片。因此，在您描述的场景中——60个纯计算型线程竞争有限CPU资源，进程C（30线程）平均获得的CPU时间确实大概率高于B（20线程），B又高于A（10线程）。这并非“不公平”，而是CFS在资源争抢下的自然结果：每个可运行线程都被视为独立调度实体，线程越多，该进程整体被调度的机会越多。
但这绝不意味着“多开线程=性能提升”。恰恰相反，无节制创建线程会引发严重开销：
- 上下文切换激增：每毫秒频繁切换数百个线程，消耗大量CPU周期；
- 缓存局部性破坏：线程分散在不同CPU核心，导致L1/L2缓存命中率骤降；
- 内存占用膨胀：每个线程默认需几MB栈空间（如Linux默认8MB），30个线程即240MB+仅栈内存。
// 反例：盲目增加OS线程数（不推荐）
func main() {
runtime.GOMAXPROCS(100) // 强制使用100个OS线程
// 启动1000个goroutine —— 实际仍受限于OS线程池，且加剧争抢
}
Go语言的设计哲学正源于对此问题的深刻反思。Go运行时采用M:N调度模型（M个goroutine映射到N个OS线程）：
-
GOMAXPROCS默认等于逻辑CPU核心数（如8核机器默认为8），严格限制后台OS线程池大小； - 数千个goroutine由Go调度器在少量OS线程上协作式调度（非抢占式，但由GC、系统调用等触发让出）；
- 当goroutine阻塞（如网络IO、channel等待）时，Go调度器自动将其挂起，并唤醒其他goroutine，避免OS线程空转。
因此，在典型负载下（非CPU饱和），一个设置 GOMAXPROCS=8 的Go程序启动30个goroutine，其吞吐量与直接创建30个OS线程的C程序基本相当——但内存开销降低一个数量级，上下文切换减少90%以上。
✅ 正确实践：
- 优先通过
goroutine + channel组织并发逻辑，而非堆砌OS线程；- 仅当明确需要绑定CPU核心（如实时计算）时，才谨慎调整
GOMAXPROCS；- 使用
pprof分析真实瓶颈：99%的性能问题源于IO阻塞、锁竞争或算法复杂度，而非“线程不够”。
简言之：线程是资源争夺的“票数”，而goroutine是高效利用每一张票的“策略”。真正的并发优化，永远始于理解负载特征，而非盲目增加调度单元。
