并发系统：Go 与 Erlang 调度器实现与设计深度解析

[htoooth]

Go 与 Erlang 调度器实现与设计深度解析

1. 引言

1.1. 并发编程的挑战

随着多核处理器的普及，软件开发面临着如何有效利用并行硬件以提升性能和响应能力的挑战。传统的基于线程的并发模型虽然提供了并行执行的手段，但其固有的复杂性，如资源开销大、同步困难、易于产生死锁和竞态条件等问题，使得并发编程充满挑战 1。开发者需要更高效、更易于管理的并发抽象。

1.2. Go 与 Erlang：为并发而生

Go 和 Erlang 是两种现代编程语言，它们都将简化并发编程作为核心设计目标，但采用了不同的哲学和技术路径，适用于不同的应用领域。

• Go 语言：由 Google 设计，旨在提供一种用于构建高效、可扩展网络服务和系统级工具的语言 1。它强调开发效率、简洁的语法以及在现代多核硬件上的高性能表现。
• Erlang/OTP：起源于爱立信的电信领域，专为构建大规模并发、分布式、高容错和高可用的系统而设计 4。其核心优势在于处理海量并发连接、实现软实时响应和构建“永不宕机”的应用 7。

1.3. 调度器的核心作用

在 Go 和 Erlang 中，运行时调度器（Scheduler）是其并发模型实现的核心。调度器负责将语言层面的并发单元（Go 的 Goroutine 和 Erlang 的 Process）映射到操作系统（OS）线程上执行，并管理它们的生命周期和资源分配。两者调度器的设计和实现机制的差异，直接决定了它们各自的并发特性和适用场景。

1.4. 报告范围与结构

本报告旨在深入剖析 Go 的 M:P:G 调度器和 Erlang 的 BEAM VM 调度器的内部实现细节、设计理念及关键差异。报告将依次详细探讨 Go 调度器、Erlang 调度器，然后进行对比分析，最后总结各自如何通过其实现机制达到设计目标。本报告面向对并发模型、运行时系统有深入了解需求的软件工程师、系统架构师或研究人员。

2. Go 调度器：实现高效的 CPU 密集型并发

Go 语言通过其 M:P:G 调度模型，旨在高效地利用多核 CPU，降低并发编程的开销，并提供简洁的并发原语（goroutine 和 channel）。

2.1. M:P:G 模型详解

Go 调度器的核心是 M:P:G 模型，它管理着三种关键资源 1。

• G (Goroutine)：代表一个 Goroutine，是 Go 语言中的基本并发执行单元。它本质上是一个轻量级的协程 2，包含要执行的函数及其上下文（如栈指针、状态）。Goroutine 的创建成本极低，初始栈空间仅需几 KB 10。当 Goroutine 退出时，其 g 对象会被回收并放入池中复用 8。
• M (Machine)：代表一个内核级 OS 线程，是实际执行 Go 代码（用户代码、运行时代码或系统调用）的载体 1。M 的数量可以动态变化，尤其是在 Goroutine 进行阻塞系统调用时，可能会创建新的 M 8。
• P (Processor)：代表执行 Go 代码所需的上下文和资源，如调度器状态、内存分配器缓存（mcache）、本地可运行 Goroutine 队列（LRQ）等 3。P 的数量在程序启动时由环境变量 GOMAXPROCS 决定，通常默认等于 CPU 核心数 10。P 可以看作是 Go 调度器层面的逻辑处理器。

P 的关键作用：P 是连接 G 和 M 的桥梁。一个 M 必须持有（acquire）一个 P 才能执行 G 8。GOMAXPROCS 实际上限制了同时运行 Go 代码的 M 的数量（即并行度）9。P 的引入（Go 1.1 版本）是 Go 调度器实现高效多核扩展的关键架构变革 3。它解决了早期 GM 模型中存在的全局调度器锁（Sched.Lock）导致的严重性能瓶颈 3。通过将 G 队列和内存缓存等资源与 P 绑定，实现了调度状态的分散化，从而为高效的 work-stealing 机制奠定了基础 3。当 M 因为系统调用等原因阻塞时，它会释放 P，使得 P 可以被其他 M 获取，继续执行其他 G，从而保证 GOMAXPROCS 个 P 对应的计算资源能够持续运行 Go 代码 8。

交互流程：调度器的核心任务是将 G（待执行的任务）、M（执行者）和 P（执行所需的资源和权限）匹配起来 8。程序启动时会创建初始的 M0 和 G0 2。

2.2. Goroutine 生命周期与调度流转

• 创建：使用 go 关键字创建 Goroutine 9。新创建的 G 通常会被放入当前 P 的本地运行队列（LRQ），或者有时会放入全局运行队列（GRQ）14。
• 运行队列 (Run Queues)：Go 调度器使用两级队列结构来管理可运行的 G 8：
  • 本地运行队列 (Local Run Queue, LRQ)：每个 P 拥有一个独立的 LRQ，存储待在该 P 上运行的 G 10。M 优先从其关联 P 的 LRQ 中获取 G 来执行。这提高了缓存局部性并减少了队列访问冲突 17。
  • 全局运行队列 (Global Run Queue, GRQ)：存在一个所有 P 共享的 GRQ 14。通常用于存放刚创建的 G，或从阻塞状态唤醒但其原 P 不可用的 G。
• 调度循环：持有 P 的 M 会不断从 P 的 LRQ 中取出 G 并执行。当 G 执行完毕、阻塞（如 channel 操作、系统调用、锁等待）或主动让出（runtime call）时，M 会选择下一个 G 执行 10。
• GRQ 检查：为了防止 GRQ 中的 G 饿死（starvation）并保证一定的公平性，调度器会周期性地（大约每 61 次调度检查一次 LRQ 后）检查 GRQ 是否有 G 需要执行 18。这个 1/61 的检查策略是在本地执行效率（LRQ 访问快，低竞争）和全局公平性（确保 GRQ 任务得到执行）之间的一种权衡 18。单独依赖 LRQ 可能导致负载不均，而单独依赖 GRQ 则会重新引入全局锁竞争 3。
• 调度时机：调度器获得执行机会（即 M 可以选择运行哪个 G）的关键点包括：go 关键字创建 G 时、垃圾回收（GC）时、系统调用前后、channel 操作、sync 包中的同步原语操作时 20。

2.3. Work-Stealing 机制详解

Work-stealing 是 Go 调度器实现负载均衡和保持高 CPU 利用率的核心机制 16。

• 触发条件：当一个 M 发现其关联的 P 的 LRQ 为空时，它会尝试从其他地方“窃取”任务 10。
• 窃取流程：
  1. 检查自身的 LRQ（确认为空）。
  2. 检查 GRQ（根据 1/61 规则或在窃取失败后）17。
  3. 检查网络轮询器（network poller）是否有就绪的 G 16。
  4. 随机选择另一个 P 作为“受害者”（victim P）14。
  5. 尝试从 victim P 的 LRQ 尾部窃取大约一半的可运行 G 3。LRQ 通常实现为双端队列，本地 P 从头部取 G，窃取者从尾部偷 G，以减少竞争。
  6. 如果窃取成功，将 G 移到自己的 LRQ 并开始执行。
  7. 如果所有窃取尝试都失败（其他 P 也为空，GRQ 为空，网络轮询器无任务），M 可能会释放 P 并进入休眠状态。
• 目标：动态地将 G 在 P 之间重新分配，确保所有 P（进而所有 CPU 核心）尽可能保持忙碌状态，提高并行计算效率 16。这是 P 结构带来的关键好处之一 3。
• 自旋线程 (Spinning Threads)：为了避免 M 在短暂空闲时频繁地进入 OS 级别的阻塞和唤醒（这通常代价较高 3），调度器采用了“自旋”策略。当一个 M 找不到 G 执行时，它不会立即睡眠，而是会“自旋”一小段时间，主动查找任务 3。
  • 持有 P 的 M 会在 LRQ、GRQ、网络轮询器中查找 G，并尝试 work-stealing。
  • 没有 P 的 M 会查找空闲的 P。
  • 最多允许 GOMAXPROCS 个 M 同时处于自旋状态。
  • 当有 G 变为 runnable 时，如果存在空闲的 P 且没有其他 M 在自旋，调度器会唤醒一个 M 并让它进入自旋状态。
  • 自旋的 M 一旦找到工作（G 或 P），就会退出自旋状态。
  • 这种机制通过牺牲少量 CPU 时间进行主动轮询，来换取更快的任务响应速度和更低的 OS 调度开销，尤其是在负载较高、任务频繁出现的情况下 3。

2.4. 阻塞操作的处理

Go 调度器对不同类型的阻塞操作采取了不同的处理策略，这是其高效性的关键之一。

• 阻塞系统调用 (Blocking Syscalls)：当 G 执行一个会阻塞 M 的系统调用时（如文件 I/O）13：
  1. 执行该 G 的 M 即将进入阻塞状态。
  2. M 会释放其绑定的 P，将 P 返回到空闲 P 池 8。
  3. M 进入系统调用阻塞状态。
  4. 运行时系统可能会唤醒或创建一个新的 M 来接管这个 P（如果 P 的 LRQ 中还有其他 G 或 GRQ 中有 G），以保证 GOMAXPROCS 的并行度不受影响 3。
  5. 当系统调用返回后，M 会尝试重新获取一个 P 来恢复执行 G（可能是原来的 G 或其他 G）8。如果暂时没有空闲 P，G 会被放入 GRQ 或某个 LRQ，M 可能会进入休眠 9。
• 网络 I/O (Network I/O)：Go 运行时内置了一个高效的网络轮询器（netpoller），它利用了操作系统提供的非阻塞 I/O 机制（如 Linux 的 epoll、BSD 的 kqueue）14。当 G 发起网络 I/O 操作时：
  1. G 被置于等待状态，其网络请求被注册到 netpoller。
  2. 执行该 G 的 M 不会 阻塞，也 不会 释放 P 14。
  3. M 可以立即从 P 的 LRQ 中获取并执行下一个 G。
  4. 当网络 I/O 操作完成时，netpoller 会通知调度器，对应的 G 会被重新放入某个运行队列（通常是 LRQ）等待执行 16。
• 通道操作与同步原语：当 G 在通道上阻塞（发送或接收）或等待 sync 包中的锁时，它同样会被置于等待状态，其状态会被记录，然后 M 会切换去执行 P 的 LRQ 中的其他 G 14。当阻塞条件满足时（如通道对端就绪），G 会被唤醒并放回运行队列。

这种对系统调用和网络 I/O 的差异化处理是一项重要的优化。系统调用是 M 级别的阻塞，必须释放 P 以维持 Go 代码的并行度。而网络轮询器将常见的网络 I/O 转化为 G 级别的阻塞，避免了 M 的阻塞和 P 的频繁切换，极大地降低了 OS 线程创建和调度的开销，使得 Go 非常适合编写高并发的网络服务器 21。

2.5. Goroutine 抢占

Go 调度器本质上是协作式的，G 会在特定的“安全点”（如函数调用、channel 操作、系统调用等）主动或被动地让出执行权 21。

• 抢占的需求：在早期版本中，如果一个 G 陷入长时间的纯计算循环，没有任何协作点，它可能会饿死（starve）同一 P 上的其他 G 10。
• 抢占机制 (Go 1.14 及以后)：为了解决公平性问题，Go 引入了基于信号的异步抢占机制 10。
  • 运行时会监控 G 的执行时间。如果一个 G 连续运行超过一个阈值（例如 10ms 10），运行时会向执行该 G 的 M 发送一个信号。
  • M 收到信号后，会在一个安全的时机（通常是函数入口或循环回边处，通过编译器插入的检查点）中断当前 G 的执行。
  • 被抢占的 G 会被放回运行队列，M 则可以调度执行 P 上的其他 G。
• 这种抢占是为了保证公平性而加入的补充机制，并非像 Erlang 那样是基于时间片或工作量的核心调度方式。它确保了即使存在行为不佳的 G，系统的响应性也不会完全丧失。

2.6. Goroutine 栈管理

Goroutine 的轻量级特性很大程度上归功于其高效的栈管理机制。

• 初始小栈：每个 G 启动时只分配一个很小的栈空间，通常是 2KB 10。这远小于 OS 线程默认的兆字节级别的栈 10。
• 动态增长（连续栈）：当 G 的函数调用需要更多栈空间时，栈可以按需增长 11。
  1. 编译器会在函数入口处插入检查代码，判断当前栈空间是否足够 12。
  2. 如果空间不足，运行时会调用 runtime.morestack。
  3. 分配一个新的、更大的栈段（通常是原大小的两倍）12。
  4. 将旧栈的内容完整地拷贝到新栈段 11。
  5. 调整栈内的指针（通过垃圾回收器使用的栈映射信息）以指向新地址 12。
  6. G 在新栈上恢复执行。
• 栈收缩：在垃圾回收期间，如果运行时检测到 G 的栈使用率很低，也可以收缩其栈空间（具体机制未在提供的信息中详述，但动态性是双向的）。
• 历史演进：Go 1.3/1.4 之前使用分段栈（segmented stacks），存在“热分裂”（hot split）等性能问题 24。之后改为连续栈，虽然增长时需要拷贝，但实现更简单，性能更可预测 12。
• 栈大小限制：每个 G 的栈大小有上限（例如 1GB 12），防止无限递归耗尽内存。深度递归仍然可能导致栈溢出 12。

动态栈管理是 Go 能够轻松支持成千上万个 Goroutine 的关键。它避免了为每个并发任务预留大量固定内存，显著降低了并发的内存开销，使得开发者可以更自由地使用 Goroutine 而不必过分担心资源消耗 11。

2.7. Go 调度器设计哲学与目标

Go 调度器的设计体现了以下核心原则和目标：

• 高效利用多核：通过 M:P:G 模型和 work-stealing 机制，最大化 CPU 利用率，实现真正的并行执行 3。
• 低开销并发：使 Goroutine 的创建、销毁和上下文切换成本远低于 OS 线程，鼓励开发者使用大量 Goroutine 1。
• 开发者友好：通过 go 关键字和 channel 提供简洁易用的并发编程接口，隐藏底层复杂的线程管理和同步细节 1。
• 可伸缩性：使 Go 应用程序能够随 CPU 核心数的增加而有效扩展其性能 16。
• 优化重点：主要针对网络 I/O 密集型和 CPU 密集型任务进行优化，这与 Go 在网络服务和系统工具领域的广泛应用相符。

3. Erlang 调度器：支撑大规模并发与容错

Erlang 的调度器运行在 BEAM 虚拟机之上，其设计目标是支持极大规模的并发进程、提供高容错能力和内建的分布式计算支持，并满足软实时系统的需求。

3.1. BEAM 虚拟机与 OTP 框架

• BEAM (Bogdan/Björn's Erlang Abstract Machine)：是 Erlang（以及 Elixir 等基于 BEAM 的语言）的官方虚拟机 4。它负责执行编译后的 Erlang 字节码（.beam 文件）。BEAM 由 C 语言实现 28，并提供了 Erlang 语言核心特性的底层支持，包括：轻量级进程创建与调度、内存分配与垃圾回收、异步消息传递、定时器、I/O 处理、分布式通信等 4。
• ERTS (Erlang Run-Time System)：包含了 BEAM 虚拟机、预加载的核心模块、代码加载器以及其他运行时支持库 6。通常我们运行 erl 命令启动的就是 ERTS。
• OTP (Open Telecom Platform)：并非操作系统，而是一套基于 ERTS 的库、设计原则和工具集 4。OTP 提供了构建健壮、并发、分布式系统的标准组件和模式，例如 gen_server（通用服务器行为）、supervisor（监控树用于容错）、application（代码和进程组织单元）等 28。因此，Erlang 开发通常被称为 Erlang/OTP 开发 28。

BEAM、ERTS 和 OTP 共同构成了一个为并发和容错量身定制的集成生态系统。VM 的设计与语言的核心语义（进程、消息）以及 OTP 的容错模式（如监控树）紧密耦合，这是 Erlang 强大能力的基础 5。

3.2. Erlang 进程：轻量级 Actor

Erlang 的并发单元是“进程”（Process），它具有独特的特性：

• 极端轻量级：Erlang 进程由 BEAM 完全管理，与 OS 进程或线程无关 4。它们的创建和销毁非常快速，内存占用极小（初始大小约 300 个机器字，包括堆和栈 32），上下文切换开销极低（通常只是 BEAM 内部的函数调用）31。
• 完全隔离：每个 Erlang 进程拥有自己独立的内存空间，包括堆（heap）、栈（stack）和邮箱（mailbox）4。进程之间不共享任何内存 4。这种彻底的隔离是 Erlang 容错模型（“Let it crash”哲学）的基石。一个进程的失败（无论是崩溃还是 GC）不会直接影响其他进程 5。
• 通信机制：进程间唯一的通信方式是通过异步消息传递 4。发送进程通过 ! 操作符将消息发送到目标进程的邮箱。接收进程使用 receive 语句从自己的邮箱中匹配并取出消息。消息在发送时通常会被拷贝（除了大的二进制数据会使用引用计数优化）4。
• 大规模并发能力：由于其极低的资源开销和高效的管理机制，单个 Erlang 节点（ERTS 实例）可以轻松支持数十万甚至数百万个并发进程 4。

Erlang 进程是 Actor 模型 4 的典型实现。它们的隔离性和基于消息传递的通信方式，不仅简化了并发逻辑的推理，更是构建高容错系统的基础。当一个进程出错时，它可以直接崩溃，由其监控者（通常是 OTP Supervisor）根据预设策略来处理（如重启），而不会破坏系统的其他部分 4。

3.3. BEAM 调度器架构

BEAM 调度器负责在可用的 CPU 核心上执行 Erlang 进程。

• 多调度器 SMP 支持：在支持 SMP（对称多处理）的系统上，BEAM 会启动多个调度器线程（Scheduler Threads），每个调度器线程通常绑定到一个逻辑 CPU 核心上运行 5。这使得 Erlang 进程可以在多个核心上实现真正的并行执行。可以通过 +S 启动参数或 erlang:system_info(schedulers_online) 来配置和查看调度器数量 39。
• 调度器类型：为了应对不同类型的任务并保护系统的响应性，BEAM 区分了几种调度器 44：
  • 普通调度器 (Normal Schedulers)：这是主要的调度器类型，负责执行常规的 Erlang 字节码、安全的 BIF（内建函数）和 NIF（本地实现函数）。它们管理进程的运行、挂起、消息传递和触发 GC。其数量通常等于 CPU 核心数，由 +S 参数控制。
  • 脏 CPU 调度器 (Dirty CPU Schedulers)：专门用于执行那些可能长时间运行且无法保证通过正常 reduction 计数让出的 CPU 密集型 NIF 或 BIF。将这些任务移交给脏 CPU 调度器可以防止它们阻塞普通调度器，从而保证其他 Erlang 进程的执行。默认会启动少量（例如，核心数个）脏 CPU 调度器。
  • 脏 I/O 调度器 (Dirty IO Schedulers)：专门用于执行可能阻塞的 I/O 操作或长时间运行的 I/O 密集型 NIF。与脏 CPU 调度器类似，它们的存在是为了将潜在的阻塞操作隔离，避免影响普通调度器的实时性。默认也会启动少量脏 I/O 调度器。
• 架构演进：Erlang 调度器的队列管理经历了演变：
  • R11B 之前：单调度器，单全局运行队列 39。简单但无并行。
  • R11B/R12B：多调度器，共享一个全局运行队列 39。引入了并行，但也带来了严重的锁竞争瓶颈 39。
  • R13B 之后：多调度器，每个调度器拥有自己独立的运行队列 6。大大减少了锁竞争，提高了可伸缩性，但需要引入负载均衡机制。

将调度器分为普通和“脏”类型，是 Erlang 为维护其软实时特性而做出的重要设计决策。它认识到与 C 代码（NIFs/BIFs）的交互可能会破坏基于 reduction 的精细抢占机制，因此提供了专门的执行环境来隔离这些潜在的干扰源，保护核心 Erlang 进程调度的响应性 6。

3.4. 运行队列管理

在 R13B 之后的现代 Erlang 系统中，每个普通调度器都管理着自己的一组运行队列（Run Queues）。

• 每调度器队列：每个普通调度器维护独立的运行队列，存放分配给它执行的、处于可运行状态的 Erlang 进程 6。一个进程通常会保持与某个调度器的关联，除非被负载均衡机制迁移 6。
• 优先级队列：Erlang 支持为进程设置不同的优先级，调度器会根据优先级来选择下一个要执行的进程 6。通常有四个级别：max（最高）、high、normal（默认）、low（最低）。
• 队列结构与调度策略：
  • 调度器严格按照优先级顺序处理队列：只有当 max 优先级队列为空时，才会处理 high 优先级队列；只有当 high 队列也为空时，才会处理 normal/low 队列 6。max 优先级通常保留给系统内部的关键任务使用 7。
  • normal 和 low 优先级共享同一个队列，采用一种加权的公平调度策略。例如，调度器可能在执行了大约 8 个 normal 进程的 reduction 量后，再执行一个 low 优先级的进程（如果队列中有的话），以确保 low 进程不会完全饿死，但 normal 进程得到优先处理 7。
  • 在同一优先级队列内部，进程通常按照 FIFO（先进先出）的顺序被调度 6。
• 锁优化：由于运行队列是调度器性能的关键路径，Erlang 运行时系统投入了大量精力来优化其访问。通过将进程状态信息整合到进程控制块（PCB）中，并广泛使用原子操作来读取和更新状态，显著减少了在判断进程状态、决定入队位置等操作中对运行队列加锁的需求 47。这对于支撑大规模并发至关重要。

多级优先级队列的设计允许系统区分任务的紧急程度，保证关键操作的及时响应。而针对 normal 和 low 的加权公平策略则是在保证基础公平性的前提下，倾向于执行主要的应用程序逻辑。对锁的持续优化则反映了在高并发场景下，即使是微小的锁竞争也可能成为性能瓶颈 39。

3.5. 基于 Reduction 计数的抢占式调度

Erlang 的调度是抢占式的，但其抢占机制并非基于时间片，而是基于“工作量”——即 Reduction 计数 6。

• Reduction 的概念：一个 Reduction 是 Erlang VM 定义的一个抽象的工作量单位。粗略地说，一次函数调用计为一个 Reduction 6。复杂的操作或 BIF 调用可能消耗更多的 Reduction。
• Reduction 配额：当一个进程被调度器选中执行时，它会被分配一个 Reduction 配额（或称“时间片”，但以 Reduction 为单位），例如 2000 或 4000 reductions 6。
• 抢占触发：进程会一直执行，直到以下任一情况发生：
  • 它消耗完了当前配额的所有 Reduction。BEAM 会在每次函数调用（或其他计入 Reduction 的操作）时检查并递减计数器 6。
  • 它执行了一个阻塞操作，例如调用 receive 但邮箱中没有匹配的消息，或者等待定时器到期 6。
  • 它显式地调用 yield()（不推荐常规使用）7。
• 抢占后果：一旦触发抢占（无论是 Reduction 耗尽还是阻塞），当前进程会被挂起，其状态会被保存，然后它会被放回其调度器的相应运行队列的末尾（根据优先级），调度器接着选择下一个可运行的进程执行。
• 目标与效果：这种基于 Reduction 的抢占机制确保了：
  • 公平性：没有进程能无限期地霸占 CPU。
  • 细粒度：抢占发生在函数调用级别，粒度非常细。
  • 软实时响应性：由于抢占频繁且基于实际工作量，系统能够快速响应新事件（如消息到达），提供了可预测的低延迟特性 5。计算密集型任务会更快地耗尽 Reduction 配额并让出 CPU。

与基于固定时间片的抢占相比，Reduction 计数能更公平地对待不同计算复杂度的任务，是 Erlang 实现其软实时目标的关键技术 6。

3.6. 负载均衡：迁移与任务窃取

在每个调度器拥有独立运行队列的模型下，需要机制来确保工作负载在所有调度器之间均匀分布，以充分利用所有 CPU 核心 6。Erlang 使用了两种互补的负载均衡策略。

• 目标：在调度器之间平均分配可运行的 Erlang 进程，最大化系统吞吐量和 CPU 利用率，同时尽可能将频繁通信的进程保留在同一调度器上以利用缓存局部性 6。
• 机制：
  • 迁移 (Migration)：这是一种周期性的、更主动的负载均衡机制 6。系统会定期（例如，基于全局执行的 Reduction 总量触发 6）收集所有调度器运行队列的负载信息（如最大队列长度 47）。基于这些信息，系统会计算出一个“迁移计划”，确定哪些调度器是“过载”的，哪些是“欠载”的，并建立起迁移路径。然后，过载调度器会将一部分进程（根据一定规则选择）迁移到欠载调度器的运行队列中。为了高效实现，关于迁移路径和队列长度限制等“固定”的负载均衡信息被存储在全局内存中，并使用原子操作进行访问，以避免在频繁的进程入队决策中产生锁竞争 47。
  • 任务窃取 (Task Stealing)：这是一种反应式的机制 6。当一个调度器执行完其所有运行队列中的进程，变为空闲状态时，它不会立即休眠。相反，它会随机选择另一个调度器作为目标，并尝试从目标调度器的运行队列中“窃取”一个可运行的进程（通常是最高优先级的那个）来执行。这为处理突发性空闲提供了即时响应。

Erlang 的负载均衡策略结合了全局视角下的周期性调整（迁移）和局部空闲时的机会性补偿（窃取）。这种设计比 Go 的纯随机 work-stealing 更为复杂，它试图基于更全面的负载信息进行更智能的平衡，可能更适合处理 Erlang 系统中常见的、由大量异构进程（不同优先级、不同状态）组成的复杂工作负载，以及可能存在的 NUMA 架构影响 48。对全局平衡信息的无锁读取优化 47 表明了负载均衡操作对性能的敏感性。

3.7. 进程内存管理：每进程堆与垃圾回收

Erlang 的内存管理与其进程模型和容错哲学紧密相关。

• 每进程内存：如前所述，每个 Erlang 进程拥有独立的堆和栈，它们通常在同一块内存区域中相向增长 34。初始分配很小（如 233 字 32），并根据需要动态扩展 32。
• 垃圾回收 (GC)：
  • 每进程独立 GC：这是 Erlang GC 最核心的特点。垃圾回收是针对单个进程独立进行的 4。当一个进程需要分配内存但其堆空间不足时，会触发该进程的 GC 34。重要的是，GC 只会暂停被回收的那个进程，而不会影响系统中的其他进程或调度器 35。
  • 分代拷贝回收 (Generational Copying Collector)：BEAM 主要使用分代式的半空间拷贝回收器（基于 Cheney 算法）34。进程堆被分为年轻代（young heap/allocation heap）和老年代（old heap）。新对象在年轻代分配。Minor GC 只回收年轻代，存活的对象会被拷贝到另一个半区（to-space），多次存活的对象会被晋升（拷贝）到老年代 34。这种方式效率较高，因为大部分对象都是“朝生夕灭”的。
  • Fullsweep GC：当老年代空间不足或经过一定次数的 Minor GC 后，会触发 Major GC（或称 Fullsweep）34。Fullsweep 会回收年轻代和老年代中的所有垃圾，并将所有存活对象拷贝到一个新的组合空间中。Fullsweep 的暂停时间会比 Minor GC 长。
  • 堆大小调整：GC 后，运行时会根据存活对象的大小动态调整进程堆的大小，可能会增长或收缩 32。可以通过 min_heap_size 选项设置最小堆大小 32。
  • 大型二进制数据 (Large Binaries)：为了避免在进程间传递大块数据时进行昂贵的拷贝，大小超过 64 字节的二进制数据（Binaries）通常存储在一个全局共享的、基于引用计数的堆（Refc Heap）中 35。进程堆中只存储指向这些共享二进制数据的引用（ProcBin）。当引用计数归零时，共享堆中的二进制数据才会被回收 37。需要注意，创建子二进制（sub-binary）时，为了效率，通常只创建新的引用指向原二进制的一部分，这可能导致原二进制因为子二进制的存在而无法被及时回收 35。
  • 原子 (Atoms)：原子是全局唯一的常量标识符，存储在全局原子表中。默认情况下，原子一旦创建就不会被垃圾回收 50。如果应用程序从外部输入动态创建大量原子，可能导致原子表耗尽内存。有提案（如 EEP-20）讨论实现可回收的原子，但这会带来额外的复杂性和性能开销 50。

每进程 GC 是 Erlang 实现软实时和高容错的关键支柱。它将 GC 暂停的影响局部化到单个进程，避免了全局“Stop-The-World”暂停对整个系统造成的冲击，使得系统整体延迟更加可预测 35。这也鼓励了将系统设计为大量小进程协作的模式，因为单个大进程的 GC 暂停会更长。引用计数的大二进制优化则是对纯粹消息拷贝模型的务实补充 37。

3.8. Erlang 调度器设计哲学与目标

Erlang/OTP 及其调度器的设计围绕以下核心目标：

• 大规模并发：高效地创建、管理和调度数以百万计的并发进程 4。
• 容错与弹性：通过进程隔离、监控树（OTP Supervisors）和“Let it crash”哲学构建能够自愈、持续运行的高可用系统 4。
• 内建分布式：提供透明的进程间通信和节点管理能力，简化分布式应用程序的开发 4。
• 软实时响应性：通过基于 Reduction 的细粒度抢占式调度和每进程 GC，提供可预测的低延迟保证 5。
• 多核可伸缩性：利用多调度器和负载均衡机制，在多核硬件上有效扩展性能 4。

4. 对比分析：Go vs. Erlang 调度器

Go 和 Erlang 的调度器虽然都旨在解决并发问题，但它们的设计哲学、实现机制和优化重点存在显著差异。

4.1. 特性对比

下表总结了两者调度器的关键特性差异：

特性	Go 调度器 (M:P:G)	Erlang 调度器 (BEAM)
并发单元	Goroutine (轻量级协程) 8	Process (轻量级 Actor/进程) 4
调度模型	M:N (G 通过 P 映射到 M) 18	M:N (Process 通过 Scheduler 映射到 OS 线程) 39
内存模型	共享堆 (全局 GC) + Goroutine 栈 24	每进程隔离堆/栈 (每进程 GC) 4
单元栈/堆	动态连续栈 (初始 ~2KB) 10	每进程小堆+栈 (初始 ~300 字) 32
垃圾回收	全局 Stop-the-World (有并发标记/清扫阶段)	每进程分代拷贝 GC 34
抢占机制	基于信号的异步抢占 (Go 1.14+, 保障公平) 10	基于 Reduction 计数的细粒度抢占 (内置) 6
负载均衡	随机 Work-Stealing (P 窃取 G) 14	周期性迁移 + 机会性任务窃取 (Scheduler 间) 6
阻塞调用处理	P 释放 (系统调用), 网络轮询器 (网络 I/O) 8	脏调度器 (NIFs/阻塞 I/O) 44
通信方式	Channel (同步/异步), 共享内存 (需同步) 9	异步消息传递 (拷贝) 4
主要设计目标	CPU 效率, 开发简洁性 2	大规模并发, 容错性, 低延迟 4
典型应用领域侧重	网络服务, 系统工具, CPU 密集任务 38	电信, 分布式数据库, 消息系统, 高可用系统 4

这个表格清晰地展示了两者在核心机制上的不同选择，这些选择源于它们迥异的设计目标。

4.2. 设计哲学的碰撞

• Go：务实的效率与简洁性。Go 的设计哲学可以概括为“务实”。它旨在为开发者提供一种简单、高效的方式来利用现代硬件进行并发编程 1。它优先考虑常见场景（如网络服务器）的性能和资源利用率，并力求通过简洁的语言特性（go 关键字、channel）降低并发编程的门槛。它愿意在某些方面（如全局 GC 可能带来的延迟抖动）做出妥协，以换取整体的吞吐量和易用性。
• Erlang：极致的弹性和规模。Erlang 的设计哲学则围绕着构建能够处理海量并发、能够容忍局部故障并能持续运行（高可用性）的系统 4。它追求进程间的强隔离、可预测的低延迟（软实时）和内建的分布式能力。为了这些核心保证，它不惜引入一些开销（如消息拷贝、每进程内存管理），并构建了一个更为复杂的运行时系统（BEAM + OTP）。

这两种哲学的差异根植于它们的起源：Go 源于 Google 构建大规模网络基础设施的需求 1，而 Erlang 源于爱立信构建永不停机的电信系统的需求 4。

4.3. 关键实现机制差异

这些哲学差异直接体现在具体的实现机制上：

• 并发单元与调度上下文：Go 的 P 是 M 执行 G 的“许可证”或上下文，M 和 P 的关系是动态的。Erlang 的 Scheduler 本身就是 OS 线程（M），它管理着完全独立的 Erlang 进程。这反映了 Go 更倾向于高效复用 OS 线程，而 Erlang 则构建了更彻底的虚拟机内抽象。
• 负载均衡策略：Go 的随机 work-stealing 简单、反应迅速，适合相对同质化的 CPU 密集型任务 18。Erlang 的“迁移+窃取”组合更为复杂，试图进行更全局、更具预测性的负载分配，可能更适合优先级多样、状态复杂的进程集合，以及需要考虑 NUMA 影响的场景 6。
• 内存与 GC：Go 的动态增长栈优化了 Goroutine 的初始内存成本，但全局 GC 可能成为大规模并发下的延迟瓶颈 12。Erlang 的每进程堆和 GC 以牺牲一定的内存效率（更多的小堆开销）和通信成本（消息拷贝）为代价，换取了高度可预测的系统级 GC 延迟 34。
• 阻塞与外部交互：Go 的网络轮询器是针对网络 I/O 的高效优化，而 P 的释放机制处理了通用的系统调用阻塞 14。Erlang 的脏调度器则是为了隔离任何可能破坏其软实时性的外部代码（尤其是 NIFs）或阻塞 I/O 44。

这些实现上的选择都是为了服务于各自的核心设计目标而做出的权衡。

4.4. 不同工作负载下的适用性

基于上述差异，Go 和 Erlang 在处理不同类型的工作负载时表现出不同的优势：

• CPU 密集型任务：Go 的 M:P:G 模型和高效的 work-stealing 通常能提供更高的原始计算吞吐量。Erlang 的 Reduction 计数虽然保证了公平性，但会带来微小的函数调用开销。
• 网络 I/O 密集型任务：两者都非常擅长。Go 的 netpoller 针对此场景高度优化 21。Erlang 的轻量级进程模型和异步消息传递天然适合处理大量并发连接，且其每进程 GC 可能在高负载下提供更稳定的延迟。
• 混合 I/O 或阻塞任务：对于涉及大量非网络阻塞调用（如磁盘 I/O、与 C 库交互）的场景，Go 的 M 可能会大量增加 13。Erlang 的脏调度器为此类任务提供了专门的、隔离的执行环境，可能提供更好的资源管理和系统稳定性。
• 超大规模并发（百万级任务）：Erlang 的进程模型在内存占用和管理开销上更具优势，更适合需要同时管理海量并发状态机或 Actor 的场景 4。Go 的 Goroutine 虽然轻量，但在极端数量下，栈增长和全局 GC 的影响可能更显著。
• 分布式系统：Erlang/OTP 在语言和 VM 层面就内建了强大的分布式支持（节点发现、透明消息传递、故障检测）4。Go 需要依赖第三方库来实现类似功能。
• 高容错、高可用系统：Erlang 的进程隔离、监控树（OTP）、每进程 GC 等特性是专门为构建此类系统设计的 4。在 Go 中实现同等级别的容错需要开发者付出更多努力来构建相应的模式。

因此，选择 Go 还是 Erlang，很大程度上取决于应用的核心需求是侧重于原始性能、开发简洁性，还是侧重于大规模并发下的稳定性、容错能力和可预测的延迟。

5. 结论：实现机制如何达成设计目标

Go 和 Erlang 的调度器通过各自精心设计的实现机制，成功地支撑了它们的设计哲学和目标。

5.1. Go：高效、可伸缩的并发

• M:P:G 模型 通过 P 控制并行度，将 G 高效映射到 M，实现了对多核资源的有效利用 3。
• Work-Stealing 机制确保了 CPU 核心的负载均衡，最大化了计算资源的利用率，提升了并行任务的吞吐量 16。
• 动态增长的 Goroutine 栈 大幅降低了创建并发单元的内存成本，使得开发者可以轻松使用大量 Goroutine 10。
• 集成的网络轮询器 专门优化了网络 I/O 场景，避免了 M 的阻塞和 P 的切换，显著提高了网络服务的性能和效率 14。
• 基于信号的抢占 (Go 1.14+) 弥补了协作式调度的不足，保证了系统的公平性和响应性。

综合来看，Go 的调度器通过这些务实且高效的机制，成功实现了其设计目标：提供一种简单易用、性能优越且能够充分利用现代多核硬件的并发编程模型，特别适合构建高性能网络服务和系统工具。

5.2. Erlang：大规模、高弹性、软实时

• 极端轻量级、隔离的进程 模型是构建大规模并发系统的基础，允许系统同时管理数百万个独立的计算单元 4。
• 每进程独立的垃圾回收 机制将 GC 暂停的影响局部化，避免了全局停顿，为系统的低延迟和高可用性提供了关键保障 35。
• 基于 Reduction 计数的抢占式调度 提供了细粒度、基于工作量的公平调度，是实现软实时响应性的核心 7。
• 异步消息传递 不仅是进程间通信的方式，也强制了进程隔离，是容错和分布式的基础 4。
• 区分普通与脏调度器 以及 复杂的负载均衡策略（迁移+窃取）进一步保证了系统在混合工作负载和外部交互下的稳定性和性能。

Erlang 的调度器及其相关机制（如内存管理、OTP 框架）共同作用，实现了其核心设计目标：构建能够支撑海量并发、具备极高容错能力、支持无缝分布式部署并满足软实时要求的健壮系统。

5.3. 总结性思考

Go 和 Erlang 的调度器代表了并发系统设计的两种不同范式。Go 选择了追求性能和简洁性的路径，其调度器是实现这一目标的强大引擎。Erlang 则选择了追求弹性和规模的路径，其调度器是构建“永不停止”的分布式系统的基石。两者都没有绝对的优劣，它们的成功在于其实现机制与其设计哲学的高度统一。对于系统架构师和开发者而言，深刻理解这两种调度器的内部工作原理和设计取舍，是根据具体应用场景和需求做出明智技术选型的关键。

Works cited

1. Analysis of the Go runtime scheduler - Department of Computer Science, Columbia University, accessed April 28, 2025, https://www1.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf
2. (Golang Triad)-I-Understanding the Golang Goroutine Scheduler GPM Model - DEV Community, accessed April 28, 2025, https://dev.to/aceld/understanding-the-golang-goroutine-scheduler-gpm-model-4l1g
3. Scalable Go Scheduler Design Doc - Google Docs, accessed April 28, 2025, https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit
4. BEAM vs JVM: comparing and contrasting the virtual machines - Erlang Solutions, accessed April 28, 2025, https://www.erlang-solutions.com/blog/beam-jvm-virtual-machines-comparing-and-contrasting/
5. The BEAM-Erlang's virtual machine -, accessed April 28, 2025, https://www.erlang-solutions.com/blog/the-beam-erlangs-virtual-machine/
6. The BEAM Book: Understanding the Erlang Runtime System - Happi, accessed April 28, 2025, https://blog.stenmans.org/theBeamBook/
7. Breakdown of Scheduling in Erlang - Mudassar Ali, accessed April 28, 2025, https://mudssrali.com/blog/breakdown-of-scheduling-in-erlang
8. Scheduler structures - - The Go Programming Language, accessed April 28, 2025, https://go.dev/src/runtime/HACKING
9. Go's Concurrency Decoded: Goroutine Scheduling - DEV Community, accessed April 28, 2025, https://dev.to/leapcell/gos-concurrency-decoded-goroutine-scheduling-1gfc
10. The Go Scheduler: How I Learned to Love Concurrency in 2025 - ByteSizeGo, accessed April 28, 2025, https://www.bytesizego.com/blog/go-scheduler-deep-dive-2025
11. What is Goroutine - DEV Community, accessed April 28, 2025, https://dev.to/ankitmalikg/what-is-goroutine-1j6d
12. Stack management and growth - Mastering Concurrent Programming with Go: From Fundamentals to Advanced Patterns | StudyRaid, accessed April 28, 2025, https://app.studyraid.com/en/read/12314/397333/stack-management-and-growth
13. Why my program of golang create so many threads? - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/27600587/why-my-program-of-golang-create-so-many-threads
14. Go scheduler: Ms, Ps & Gs - Povilas Versockas, accessed April 28, 2025, https://povilasv.me/go-scheduler/
15. Why we add P rather than simply changing M in the design of Go scheduler?, accessed April 28, 2025, https://stackoverflow.com/questions/60481941/why-we-add-p-rather-than-simply-changing-m-in-the-design-of-go-scheduler
16. software/golang/work-stealing.md at main - GitHub, accessed April 28, 2025, https://github.com/BlendedFeelings/software/blob/main/golang/work-stealing.md
17. Why Golang scheduler uses two Queues (global run queue and local run queue) to manage goroutine? - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/75037734/why-golang-scheduler-uses-two-queues-global-run-queue-and-local-run-queue-to-m
18. Go's work-stealing scheduler · rakyll.org, accessed April 28, 2025, https://rakyll.org/scheduler/
19. The Golang Scheduler - Kelche, accessed April 28, 2025, https://www.kelche.co/blog/go/golang-scheduling/
20. Mastering Concurrency: Unveiling the Magic of Go's Scheduler - SAP Community, accessed April 28, 2025, https://community.sap.com/t5/additional-blogs-by-sap/mastering-concurrency-unveiling-the-magic-of-go-s-scheduler/ba-p/13577437
21. Scheduling In Go : Part II - Go Scheduler - Ardan Labs, accessed April 28, 2025, https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html
22. An Efficient Work-Stealing Scheduler for Task Dependency Graph - Tsung-Wei Huang, accessed April 28, 2025, https://tsung-wei-huang.github.io/papers/icpads20.pdf
23. Concurrency in Go using Goroutines and Channels. - DEV Community, accessed April 28, 2025, https://dev.to/dpuig/concurrency-in-go-using-goroutines-and-channels-nhc
24. Why is a Goroutine's stack infinite - Dave Cheney, accessed April 28, 2025, https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite
25. Why you can have millions of goroutines but only thousands of Java threads - Hacker News, accessed April 28, 2025, https://news.ycombinator.com/item?id=18159647
26. How Stacks are Handled in Go - The Cloudflare Blog, accessed April 28, 2025, https://blog.cloudflare.com/how-stacks-are-handled-in-go/
27. What things, other than stack sizes, makes goroutines better than pthreads under certain situations? : r/golang - Reddit, accessed April 28, 2025, https://www.reddit.com/r/golang/comments/18omkld/what_things_other_than_stack_sizes_makes/
28. OTP at a High Level - Adopting Erlang, accessed April 28, 2025, https://adoptingerlang.org/docs/development/otp_high_level/
29. A brief introduction to BEAM - Erlang/OTP, accessed April 28, 2025, https://www.erlang.org/blog/a-brief-beam-primer/
30. Deep Diving Into the Erlang Scheduler - AppSignal Blog, accessed April 28, 2025, https://blog.appsignal.com/2024/04/23/deep-diving-into-the-erlang-scheduler.html
31. Processes — Erlang System Documentation v28.0-rc2, accessed April 28, 2025, https://www.erlang.org/docs/28/system/ref_man_processes
32. Processes — Erlang System Documentation v27.3.3, accessed April 28, 2025, https://www.erlang.org/doc/system/eff_guide_processes.html
33. Processes — Erlang System Documentation v27.3.3, accessed April 28, 2025, https://www.erlang.org/doc/system/ref_man_processes.html
34. Erlang Garbage Collector — erts v15.2.6, accessed April 28, 2025, https://www.erlang.org/doc/apps/erts/garbagecollection.html
35. Erlang Garbage Collection Details and Why It Matters - Hamidreza Soleimani's Blog, accessed April 28, 2025, https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
36. How the Erlang get soft-realtime with GC? - Software Engineering Stack Exchange, accessed April 28, 2025, https://softwareengineering.stackexchange.com/questions/145811/how-the-erlang-get-soft-realtime-with-gc
37. Garbage collection and memory management in Erlang - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/10221907/garbage-collection-and-memory-management-in-erlang
38. Erlang Garbage Collection Details and Why They Matter - Hacker News, accessed April 28, 2025, https://news.ycombinator.com/item?id=10218343
39. Erlang Scheduler Details and Why It Matters - Hamidreza Soleimani's Blog, accessed April 28, 2025, https://hamidreza-s.github.io/erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
40. How does Erlang manage to support so many light weight processes? - Reddit, accessed April 28, 2025, https://www.reddit.com/r/erlang/comments/1e5sxc2/how_does_erlang_manage_to_support_so_many_light/
41. How does an Erlang process bind to a specific scheduler? - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/6775714/how-does-an-erlang-process-bind-to-a-specific-scheduler
42. How does Erlang schedule work for multicore CPU machines? - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/7005759/how-does-erlang-schedule-work-for-multicore-cpu-machines
43. Process balancing in Erlang - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/511369/process-balancing-in-erlang
44. scheduler - Erlang/OTP, accessed April 28, 2025, https://www.erlang.org/docs/22/man/scheduler
45. Why recon reports 2 schedulers even though BEAM was supposedly started with 1?, accessed April 28, 2025, https://elixirforum.com/t/why-recon-reports-2-schedulers-even-though-beam-was-supposedly-started-with-1/63656
46. Will Erlang Scheduler make process causing re-queue problem? - Stack Overflow, accessed April 28, 2025, https://stackoverflow.com/questions/53892310/will-erlang-scheduler-make-process-causing-re-queue-problem
47. Process Management Optimizations — erts v15.2.5 - Erlang, accessed April 28, 2025, https://www.erlang.org/doc/apps/erts/processmanagementoptimizations.html
48. Go's work-stealing scheduler - Hacker News, accessed April 28, 2025, https://news.ycombinator.com/item?id=14794244
49. Strategies for managing per- process memory in Erlang - DiVA portal, accessed April 28, 2025, http://www.diva-portal.org/smash/get/diva2:1907585/FULLTEXT01.pdf
50. On garbage-collecting atoms - BEAM Chat / Discussions - Erlang Forums, accessed April 28, 2025, https://erlangforums.com/t/on-garbage-collecting-atoms/1476
51. Characterizing the Scalability of Erlang VM on Many-core Processors - kth .diva, accessed April 28, 2025, https://kth.diva-portal.org/smash/get/diva2:392243/FULLTEXT01.pdf