为何绿色线程（如Goroutine）在CPU密集型任务中性能更慢？

这个说法完全属实——在纯CPU密集、无IO/阻塞操作的场景下，以Goroutine为代表的绿色线程，性能确实会明显落后于C/Java/Rust的原生OS级线程实现。核心原因可以归结为以下几点：

1. 用户态调度的额外开销 #

绿色线程的调度由语言Runtime（而非操作系统内核）负责。以Go的M:N调度模型为例：

• 当一个Goroutine持续占用CPU（CPU密集型任务），绑定的OS线程（M）会一直被它霸占，逻辑处理器（P）无法被其他M复用，导致其他Goroutine只能等待。
• Runtime调度器需要通过定时信号或主动触发的方式抢占CPU，这一过程比内核级调度多了一层用户态到内核态的交互开销，调度效率远不如内核直接管理的原生线程。

2. 调度触发机制的局限性 #

绿色线程的调度依赖主动让出CPU（比如Go中的runtime.Gosched()、IO操作、Channel通信等隐式让出），但CPU密集型任务不会产生这类触发点。此时Runtime只能依赖定时发送的抢占信号来中断Goroutine，这不仅会带来信号处理的额外开销，还可能导致某个Goroutine长时间霸占CPU，降低整体并发吞吐量。而OS线程的抢占是内核级的，时机更精准，开销更低。

3. 缓存亲和性与内存模型的差异 #

• 原生线程的栈由内核管理，CPU的缓存亲和性更好——线程调度时，内核会尽量将线程调度到之前运行的CPU核心上，减少缓存失效的概率。
• 绿色线程的用户态栈（比如Go的动态扩容栈）在调度切换时，缓存命中率更低，尤其是在频繁切换的CPU密集场景下，缓存失效的成本会被放大，直接影响计算性能。

4. 编译器优化的天花板 #

C/Rust这类静态编译语言可以直接生成机器码，编译器能做更激进的底层优化（比如循环展开、寄存器分配、函数内联等）；Java的JIT编译器在运行后期也能生成接近原生的优化代码。而Go的编译器为了兼容Runtime的调度、动态栈等特性，部分底层优化会受到限制，在纯计算场景下，代码执行效率不如C/Rust/Java的原生线程实现。

举个直观的例子：跑一个百万次的矩阵乘法任务，用Go的Goroutine和Rust的原生线程对比，在CPU满负载的情况下，Go的吞吐量通常只有Rust的70%-90%；但如果是IO密集的网络请求场景，Go能轻松支撑十万级并发，而原生线程的并发上限受限于内核的线程数限制，差距会反过来。

内容的提问来源于stack exchange，提问作者Ashwin