文章转载于

【GMP-Go的协程与Java线程的差异分析 - Asthenia | 小红书 - 你的生活兴趣社区】

全文2612字 | 阅读需8分钟

在当今的软件开发中，高效处理并发任务是至关重要的。不同的编程语言选择了不同的并发模型，这些模型深刻地影响了程序的性能、资源消耗和开发难度。本文将深入剖析 Go 语言采用的 GMP 模型，并将其与经典的 Java 线程模型进行对比，探讨它们各自的设计哲学、实现机制及适用场景。

首先，我们聚焦于 Linux 操作系统下的 Go GMP 模型。GMP 是三个关键概念的缩写：G（Goroutine）、M（Machine）和 P（Processor）。这个模型是 Go 语言高并发能力的基石。

Go 的 GMP 模型详解

Goroutine（G）

Goroutine 是 Go 语言中的轻量级用户态线程。它由 Go 运行时管理，而非操作系统。其最显著的特点是开销极小，初始栈大小仅为 2KB，并且可以动态伸缩，因此创建和销毁的成本非常低。我们可以轻松创建数十万个 Goroutine 而不会导致系统资源耗尽。

Machine（M）

M 代表的是系统内核线程。它是真正在 CPU 核心上执行代码的实体。在 Linux 上，一个 M 直接对应一个通过 pthread 库创建的内核线程。M 的调度完全由操作系统内核负责，其创建和管理涉及系统调用，因此开销较大。

Processor（P）

P，即处理器，是 GMP 模型的精髓所在，它充当了 G 和 M 之间的连接桥梁。P 可以被理解为一个“逻辑处理器”或“调度上下文”。P 的数量默认等于程序启动时设置的 GOMAXPROCS 环境变量值，通常设置为当前机器的 CPU 逻辑核心数。每个 P 都维护着自己的本地运行队列，里面存放着等待被执行的 Goroutine。

GMP 协同工作流程

程序启动时，运行时会创建 GOMAXPROCS 个 P 并置于空闲列表。一个 M（内核线程）需要成功绑定一个 P 后才能开始执行 Goroutine。随后，M 会从其所绑定的 P 的本地运行队列中取出一个 G 来执行。这种设计优先使用本地队列，极大地减少了多线程间对全局队列的锁竞争，提升了调度效率。

text
[程序启动]
    ↓
[创建 GOMAXPROCS 个 P] ← (橙色: Processor)
    ↓
[P 放入空闲列表]
    ↓
[M 等待绑定 P] ← (绿色: Machine / 内核线程)
    ↓
[M 成功绑定一个 P]
    ↓
[M 从所绑定 P 的本地运行队列中取出一个 G]
    ↓
[G 在 M 上运行] ← (G: Goroutine)

Go 运行时的调度策略非常智能。如果一个 P 的本地队列空了，它不会让对应的 M 闲置。它会按照一定的优先级去寻找可运行的 G：首先会检查全局运行队列，其次会检查网络轮询器（处理已就绪的网络 IO），如果这些地方都没有任务，它会尝试从其他繁忙的 P 的本地队列中“偷”一半的工作过来。这种“工作窃取”算法确保了所有 CPU 核心都能得到充分利用，避免了忙闲不均的情况。

text
[P 的本地队列空了]
     ↓
[检查全局运行队列？→ 是 → 取 G]
     ↓
[否 → 检查网络轮询器？→ 是 → 取已就绪 IO G]
     ↓
[否 → 尝试“偷”其他繁忙 P 的一半任务]
     ↓
[成功 → 分配给当前 M 执行]

Go 的调度是协作式与抢占式相结合的。协作点发生在函数调用时，例如进行通道操作、执行系统调用或调用 time.Sleep。在这些时刻，Go 运行时有机会进行调度。此外，为了阻止一个 Goroutine 长时间霸占 CPU（例如一个计算密集的死循环），运行时还实现了基于信号的强制抢占机制。一个后台监控线程会检测运行时间过长的 G（默认为 10ms），并设置抢占标志，最终使其被挂起，让出 CPU 给其他 Goroutine。

text
[G 执行中]
     ↓
[发生以下任一事件？]
     ├──→ 通道操作 (chan send/receive)
     ├──→ 系统调用 (syscall)
     ├──→ time.Sleep()
     └──→ 返回函数/协程切换
          ↓
[Go 运行时进行调度]

系统调用优化

GMP 模型对系统调用的优化是其高性能的关键。当一个 Goroutine 执行了一个阻塞式的系统调用（如文件读写）时，其所在的 M 会被操作系统阻塞。此时，Go 运行时会立即将当前 P 与这个被阻塞的 M 解绑。然后，运行时会创建一个新的 M（或从休眠池中唤醒一个闲置的 M），让它与刚才解绑的 P 重新绑定，从而继续执行 P 的本地队列中的其他 Goroutine。当系统调用完成后，那个被阻塞的 G 会尝试获取一个空闲的 P 来继续执行，如果获取不到，它会被放回全局运行队列，其原来的 M 则进入休眠。这个过程确保了即使有 Goroutine 被阻塞，代表计算能力的 P 也永远不会闲着，CPU 利用率始终保持在很高水平。

Java 的线程模型

接下来，我们再看 Java 的线程模型。自 JDK 1.2 以来，Java 一直采用经典的 1:1 模型。这意味着每一个 java.lang.Thread 实例都直接映射到一个操作系统内核线程。在 Linux 上，JVM 通过调用 pthread 库来创建和管理这些底层线程。因此，Java 线程的调度、上下文切换、在多核处理器上的负载均衡等，完全交由 Linux 内核的调度器来负责。

这种模型的优点是简单可靠，直接利用了操作系统成熟且强大的线程调度能力，在多核环境下能够实现真正的并行执行，性能表现可预测。然而，其缺点也十分明显：资源开销巨大。每个 Java 线程都需要分配较大的栈内存，默认通常为 1MB，创建和销毁线程的成本很高。更重要的是，线程之间的上下文切换是“重量级”的，必须从用户态陷入内核态，由内核完成切换，代价较大。正因如此，受限于内核资源，一台机器上能够创建的线程数量是有限的，通常达到数千个已是极限，创建过多会导致内存耗尽和剧烈的上下文切换抖动，反而使性能急剧下降。此外，当一个线程执行阻塞式 IO 操作时，整个底层内核线程会被操作系统挂起，对应的 CPU 核心就可能闲置，除非此时正好有其他就绪的线程可以运行。

为了缓解线程创建和销毁的开销，Java 提供了强大的 java.util.concurrent 包，特别是线程池（ExecutorService）。通过池化技术复用已创建的线程，避免了频繁的成本。但这只是一种资源管理上的优化，并未改变其底层 1:1 模型的基本特性。

对比分析

现在，让我们对两者进行清晰的对比。

从核心关系上看，Go 的 GMP 是 M

模型，它将海量的用户态线程多路复用到少量内核线程上。而 Java 是直接的 1:1 模型。在调度器层面，Go 拥有一个在用户态实现的、高度优化的智能调度器；Java 则完全依赖内核态的操作系统调度器。这直接导致了开销上的巨大差异：Goroutine 的开销极低，而 Java 线程的开销较大。因此，在并发规模上，Go 可以轻松支撑数十万甚至上百万的并发任务，而 Java 线程的并发上限要低得多。

在应对阻塞操作方面，GMP 模型通过解绑 P 和 M 的机制实现了高效处理，保证了 CPU 的高利用率。而在 Java 模型中，线程的阻塞直接导致内核线程的阻塞，对 CPU 利用率有负面影响。从复杂度来看，GMP 模型的复杂性隐藏在 Go 运行时内部，对开发者是透明的，但实现起来非常复杂；Java 的模型则相对简单直观。

最后，它们的适用场景也因此不同。Go 的 GMP 模型尤其适合高并发、IO 密集型的应用，例如网络服务器、微服务、API 网关等，这些场景需要同时处理海量的网络连接或请求。而 Java 的线程模型在 CPU 密集型计算（线程数约等于 CPU 核心数时）以及传统的、并发量并非极端高的企业级应用中，依然表现稳健且可预测。

总结

总结来说，Go 的 GMP 模型代表了一种更现代的并发编程范式，它通过在用户态实现一个复杂的调度器，巧妙地规避了内核线程的高开销缺点，为高并发场景提供了强大的原生支持。

而 Java 的线程模型则体现了稳健和直接的设计哲学，充分信赖并依赖操作系统的基础设施。

这两种选择并无绝对优劣之分，更多地反映了语言在设计之初所要解决的核心问题以及其目标应用场景的差异。理解这些差异，有助于我们在不同的项目需求下做出更合适的技术选型。

目录