PON-Beam：面向通知的BEAM虚拟机实验，重塑Erlang并发模型

说到 Erlang 虚拟机，绝大多数人的第一反应是 BEAM、进程、消息传递、容错、热升级。Open Telecom Platform 的这套设计几乎成了高并发服务端的代名词。但我今天想聊一个不太一样的视角：如果 BEAM 的进程间通信不再依赖“消息投递”这个动作，而是把整个 VM 的调度、任务分发、状态同步都改成 Notification-Oriented（面向通知）的模型，跑起来会是什么样？这就是这次要看的 PON-Beam。

先说清楚，这不是 Erlang/OTP 官方发布的正式版本，而是一个围绕 BEAM 虚拟机做的实验性研究方向或者说概念原型。它的核心不是给你一个新的语言，而是尝试替换/改造 BEAM 内部的消息传递与调度机制，让进程之间的协作更像“事件通知”而不是“把消息投进邮箱”。对研究虚拟机实现、了解 BEAM 内部机制、或者在做高并发架构选型的人来说，这个概念值得花点时间拆开看看。

本文会围绕几个关键问题来展开：BEAM 原生的消息队列机制到底有什么短板？Notification-Oriented 的设计思路和传统 Actor 模型有什么本质差异？如果要把 PON-Beam 跑起来做验证，需要考虑哪些环境、编译和基准测试问题？最后给出一个可以复用的实验流程和排查清单。就算你暂时不打算深入改 VM，这篇文章也可以帮你重新理解 Erlang 并发模型里最容易忽略的那一层：运行时内部到底怎么处理消息。

1. 核心能力速览

在开始之前，先用一张表把 PON-Beam 的定位和主要特性做一个快速概括。

需要特别说明：因为材料里没有给出 PON-Beam 的具体仓库地址、编译参数和测试数据，所以上面表格里标“需按实际仓库说明验证”的部分，在你本地操作时要以你拉到的源码为准。不要默认它和官方 Erlang/OTP 完全一致。

2. BEAM 原生消息机制的问题在哪

理解 PON-Beam 之前，必须先回忆一下 BEAM 原生消息传递是怎么工作的。

BEAM 的并发模型基于 Erlang 进程，每个进程拥有自己的私有堆和消息邮箱，进程间不共享内存，通信方式只有一种：发送异步消息。发送方把消息复制到接收方的消息队列，接收方通过receive语句从邮箱里匹配并取出消息。这套模型的好处非常明显：无共享、天然隔离、错误隔离，配合预emptive scheduler 可以实现比较稳定的软实时特性。

但它也有几个在特定场景下容易被放大问题的地方。

第一是消息复制开销。小消息还好，大 payload 在进程间复制时的成本不能忽略。虽然 BEAM 对消息做了一些优化，比如引用计数二进制，但本质上一个进程发给另一个进程的数据需要经过队列管理。

第二是邮箱堆积。如果接收方处理不过来，发送方又持续投递，邮箱会不断膨胀，极端情况下会造成内存压力，并让消息匹配变慢。receive扫描邮箱如果存在大量不匹配的消息，会导致“选择性接收”性能下降，这是很多 Erlang 开发者踩过的坑。

第三是调度层面的被动性。经典 Erlang 调度器是抢占式的，每个进程按 reduction 数量被调度，消息到达后不会立刻触发接收进程执行，而是等调度器给这个进程时间片。对于某些事件驱动型任务，这种“到了但没立刻响应”的延迟，在微秒级高吞吐场景下会成为瓶颈。

PON-Beam 想做的，就是把“异步投递到邮箱，等接收方主动取”改成“通知驱动，消息到达即触发对应处理路径”。听上去并不复杂，但改到 VM 内部就完全不是一回事了，因为这关系到调度器、消息队列数据结构、进程状态机和垃圾回收等多个底层模块。

3. Notification-Oriented 设计思想拆解

“面向通知”这个词在软件工程里并不新鲜。观察者模式、事件驱动架构、发布订阅系统都属于这个范畴。但 PON-Beam 的 Notification-Oriented 显然不是简单地在 Erlang 上层框架里加一个事件总线，而是尝试在 VM 层做机制变更。

从项目名称推测，PON-Beam 的核心设计方向可以拆成三个层面。

第一层是进程间的通知路径。原生 BEAM 中，消息发送走的是send指令，核心动作是“入队”。而在面向通知的模型里，发送动作的重点可能是“通知接收方有事件到达”，消息本身可能通过更轻量的引用传递，真正触发执行的是通知事件本身。

第二层是调度触发逻辑。原生调度器在进程被唤醒之前，进程不知道自己有新消息。Notification-Oriented 的 VM 级实现，必然要考虑让“消息到达”成为调度器触发进程执行的直接依据，减少等待时间和唤醒延迟。

第三层是状态传播。在传统 BEAM 中，一个状态变更通过消息广播给多个进程，接收方各自处理。而在 Notification-Oriented 模型里，状态变化本身就是一等的通知对象，进程订阅的是“状态变化”而非“某条消息”。这更像一个嵌入 VM 的响应式状态传播机制。

以上三点是基于项目名和关键词的合理分析，不代表 PON-Beam 当前实现已经完全做到。研究性质的项目往往处于“设计假设 + 部分验证”阶段，所以把它理解为一种设计方向更稳妥。

从架构实践的角度看，如果 PON-Beam 真的把通知机制下沉到 VM 里，那么 Erlang/Elixir 编写分布式系统时的许多中间层框架，比如事件总线、消息代理、任务调度器，都有可能在某些场景下变得更轻。但代价也很明显：VM 层的改动会影响整个语言生态的语义，尤其是receive语义、容错模型和监控树。

4. 与 Classic Actor 模型的对比

BEAM 的进程模型通常被归为 Actor 模型。Actor 模型的三个核心特征是：封装状态、异步消息传递、通过消息地址通信。PON-Beam 如果只是换个名字，那就没意义。真正的冲突点在于它引入的 Notification-Oriented 风格，会改变 Actor 模型里“消息队列”这个关键结构在 VM 内部的实现方式。

传统 Actor 模型里，邮箱是缓冲，接收方决定何时处理。PON-Beam 的“面向通知”更像是一个进程说“我对某个事件感兴趣”，然后当事件发生时，运行时直接把控制流转移到对应处理函数。

这两者的差异可以类比为轮询与中断的差异。Actor 模型是接收方主动扫描邮箱，Notification-Oriented 是事件到达时主动触发接收方。

不过要注意，完全取消消息队列并不现实。因为进程可能正在执行其他计算，无法立刻响应通知。所以更合理的设计是混合机制：通知负责唤醒和分发，队列仍然作为缓冲，但是队列的消费方式会被重写——从扫描匹配变成按订阅关系直接路由。

这也是为什么 PON-Beam 适合拿来做实验而不是直接用于生产环境的原因。因为改到这一层，涉及的问题已经不是“某个函数怎么写”，而是“BEAM 的调度器如何重新设计”。

5. 核心模块与架构假设

如果参考 BEAM 自身的代码结构，可以大致推测 PON-Beam 会涉及这些核心模块。

5.1 消息发送模块

在erts/emulator/beam目录下，erl_message.c、erl_process.c主要负责消息发送和进程管理。PON-Beam 如果要实现通知机制，首先会改动消息从发送方复制到接收方队列的路径。

原生流程大致是：

// 伪代码，说明原生消息发送的核心路径 send_message(ToProcess, Message) { copy_message_to_queue(ToProcess, Message); if (process_is_suspended_or_waiting(ToProcess)) { schedule_process(ToProcess); } }

而通知机制的伪代码可能是：

// 伪代码，说明通知式消息发送的核心路径 send_notification(ToProcess, Notification) { route_by_subscription(ToProcess, Notification); trigger_callback(ToProcess, Notification); if (process_need_scheduling(ToProcess)) { schedule_process(ToProcess); } }

注意，这只是为了表达两种思路的差异而写的伪代码，不代表 PON-Beam 的实际源码结构。

5.2 订阅表

如果 Notification-Oriented 真正生效，VM 内部需要维护一张进程订阅表。这张表描述的是“通知类型 / 事件源 -> 订阅进程列表”。它替代的实际上是传统邮箱的广播匹配逻辑。

不过这张表需要处理并发修改，要保证进程退出时清理干净，要处理重复订阅，还要考虑通知类型的层级关系，复杂度不低。

5.3 调度器

BEAM 的调度器基于 reduction 计数，每个进程被抢占式调度。如果要实现通知即触发，调度器需要支持更高优先级的“事件驱动进程唤醒”路径。这会影响系统级进程调度、CPU 负载均衡、SMP 下的迁移策略等，改动量非常大。

5.4 垃圾回收

BEAM 的进程堆增长和 GC 策略与邮箱、消息引用息息相关。通知机制如果减少了大消息的复制，那 GC 压力会有所变化；但如果订阅表引入了更多跨进程引用，又会对 GC 的可达性分析产生新影响。这些都属于实验需要观察的部分。

再次提醒：以上是对 BEAM 源码结构和 PON-Beam 名称的合理推断，具体架构要以你拉到的项目源码为准。如果你没找到源码，把这一节当作背景理解会比当作事实引用更合适。

6. 环境准备与本地验证思路

既然 PON-Beam 是一个实验性项目，本地验证最好的方式还是从 Erlang/OTP 源码编译入手，或者基于已发布的分支代码构建。下面给出一套通用流程。

6.1 操作系统与工具链

Erlang 源码编译在 Linux/macOS 上最顺。Windows 下也可以，但需要额外的依赖配置，容易踩坑。建议先准备好：

• Linux（Ubuntu 22.04/24.04 或同类发行版）或 macOS
• 编译器：gcc / clang
• make、autoconf、m4
• OpenSSL 开发头文件（部分模块可选）
• ncurses 开发头文件
• 至少 10GB 可用磁盘空间（源码 + 编译产物）

Ubuntu 下可以用以下命令安装基础依赖：

sudo apt-get update sudo apt-get install -y build-essential autoconf m4 libncurses-dev libssl-dev unixodbc-dev

macOS 下推荐先用 Homebrew 安装依赖：

brew install autoconf automake libtool openssl ncurses

6.2 从源码构建

假设你已经拿到了 PON-Beam 的源码目录，并且它保持 Erlang/OTP 的 configure/make 构建结构，通用编译步骤如下：

cd pon-beam-src ./otp_build autoconf ./configure --prefix=$HOME/pon-beam-install make -j$(nproc) make install

注意把$HOME/pon-beam-install换成实际你想安装的路径。如果仓库里没有otp_build脚本，就使用标准的：

./configure --prefix=$HOME/pon-beam-install make -j$(nproc) make install

编译时间取决于机器配置，通常 10 到 30 分钟不等。编译完成后，用安装目录下的bin/erl启动 Erlang shell：

export PATH=$HOME/pon-beam-install/bin:$PATH erl

如果启动后能看到 Erlang/OTP 的版本信息，并且这个版本号与官方版本有差异，说明确实用的是 PON-Beam 的编译产物。

6.3 验证基础消息通信

不管 VM 怎么改动，能跑通基础并发和消息通信是最低要求。在 Erlang shell 里输入以下代码：

Pid = spawn(fun() -> receive Msg -> io:format("got ~p~n", [Msg]) end end), Pid ! hello.

如果能输出got hello，说明基础消息路径可用。如果项目实现了通知机制，接下来就可以针对订阅、触发、批量通知做专项测试。

7. 功能测试与效果验证方法

这里要区分“项目自带测试”和“我们自己做的验证实验”。研究性项目通常会有少量单元测试，但不会像商业项目那样有完整的功能矩阵。稳妥的做法是，通过 Erlang 代码调用底层机制，观察行为是否符合“面向通知”的预期。

7.1 通知触发正确性测试

测试目的：确认进程能否通过订阅关系接收到通知，以及通知触发是否按预期执行。

测试思路：创建多个进程，让它们订阅同一类型的事件，然后触发一次通知，观察所有订阅进程是否都收到。

-module(pon_test). -export([subscribe_and_notify/0]). subscribe_and_notify() -> Parent = self(), Pids = [spawn(fun() -> receive {notification, Data} -> Parent ! {received, self(), Data} after 1000 -> Parent ! timeout end end) || _ <- lists:seq(1, 5)], timer:sleep(100), %% 这里的 notify 函数取决于 PON-Beam 提供的接口 %% PON_Notify = erlang:notify(?), %% PON_Notify, receive_all(length(Pids), []). receive_all(0, Acc) -> lists:reverse(Acc); receive_all(N, Acc) -> receive Msg -> receive_all(N - 1, [Msg | Acc]) after 2000 -> {timeout, Acc} end.

这个测试的核心是验证通知机制能不能把同一事件分发给多个订阅进程。如果超过 2 秒还未收到所有进程的确认，说明订阅表或者分发逻辑存在问题。

7.2 高频率消息压力测试

测试目的：看 Notification-Oriented 模型在高频通知下是否会比经典邮箱机制有更低的延迟或更高的吞吐。

这里要注意：没有 PON-Beam 官方基准数据时，不要自己做结论。要做也是和原生 Erlang 做对比。你可以编译两个版本，一个官方 OTP，一个 PON-Beam，然后跑同样压力脚本，记录结果。

压力脚本可以参考：

-module(stress). -export([run/2]). run(Count, NumProcs) -> Parent = self(), Pids = [spawn(fun() -> receiver_loop(Parent, Count) end) || _ <- lists:seq(1, NumProcs)], timer:sleep(100), Start = erlang:monotonic_time(microsecond), lists:foreach(fun(Pid) -> spawn(fun() -> send_loop(Pid, Count) end) end, Pids), receive_all(NumProcs * Count, Start). send_loop(_Pid, 0) -> ok; send_loop(Pid, N) -> Pid ! {self(), N}, send_loop(Pid, N - 1). receiver_loop(Parent, 0) -> Parent ! done; receiver_loop(Parent, N) -> receive _ -> receiver_loop(Parent, N - 1) end.

注意这个脚本只是通用思路，真正对比时需要注意进程数量、消息大小、调度器线程数的一致性，否则对比结果没有参考价值。

7.3 批量任务体验

虽然 PON-Beam 不直接提供“批量任务”功能，但你可以利用 Erlang 并发模型来模拟批量分发：

batch_dispatch(TaskList, WorkerNum) -> Workers = [spawn(fun() -> worker_loop() end) || _ <- lists:seq(1, WorkerNum)], Tasks = queue:from_list(TaskList), lists:foreach(fun(W) -> W ! {next, Tasks} end, Workers).

这个方向适合测试 Notification-Oriented VM 在并发任务分发上的表现，但和原生版对比时同样需要控制变量。

7.4 结果判断标准

判断测试是否成功，可以从几个维度看：

• 正确性：所有订阅进程都能收到通知，没有漏发、重复。
• 延迟：通知下发到进程收到的时间差。
• 吞吐：单位时间内完成的通知分发数量。
• 内存稳定性：长时间压力测试后，邮箱或订阅表没有无界增长。
• 进程退出清理：订阅进程退出后，订阅表是否及时清理，是否出现泄漏。

8. 适用场景与使用边界

这个项目的价值不在生产环境，而在研究和学习。

适合的人群非常明确。如果你在学 BEAM 内部原理，想理解 Erlang 的消息路径到底经过哪些模块，那拿 PON-Beam 当切入点是非常好的。你可以对比它在消息发送、进程调度上做的改动，从而更直观地理解原生 BEAM 的设计取舍。

如果你在做高并发架构选型，PON-Beam 也能提供一个概念层面的参考：在什么场景下，通知驱动的并发模型比传统 Actor 模型更合适。比如高频事件流、状态广播、实时协作场景，通知机制理论上能减少调度延迟。但实际是否值得用，需要大量测试验证。

不建议把这种实验性 VM 放进核心服务。原因很简单：Erlang/OTP 的生态工具、库、调试器、性能分析器都是围绕原生 BEAM 运转的。VM 层语义变更后，很多工具未必兼容。生产环境的稳定性优先于一切。

使用边界方面，不需要特别强调版权问题，因为这属于基础软件研究。不过如果你在实验中使用第三方开源代码、抓包数据或测试脚本，还是要注意开源协议。涉及性能对比时，不要把实验数据直接包装成“PON-Beam 比官方版本快 XX%”的结论，除非你的测试方法足够严谨。

9. 资源占用与性能观察

虽然 PON-Beam 不走显存，但资源监控依然很重要。编译阶段主要看 CPU 和磁盘，运行阶段主要看内存和调度延迟。

9.1 编译期间

编译时可能出现内存占用过高，尤其是make -j$(nproc)在机器核数很多时会并行编译大量 C 文件。如果内存不足，减少并行度：

make -j2

磁盘空间不够时，优先清理源码目录下的中间文件：

make clean

9.2 运行期间

用 Erlang 自带的 observer 可以查看进程数量和内存分布：

observer:start().

如果 PON-Beam 改动了 notify 模块，可以在模块里加入统计接口，记录每次 notify 的时间。比如：

notify(Type, Data) -> Start = erlang:monotonic_time(microsecond), %% PON-Beam 提供的通知函数 %% PON_VM:notify(Type, Data), End = erlang:monotonic_time(microsecond), erlang:statistics(runtime), {Type, End - Start}.

不过这个接口不是现成的，需要根据项目源码自己接。注意不要假设一定存在notifyAPI。

9.3 对比测试的坑

做 PON-Beam 与原生 BEAM 对比时，最容易出现的问题有三个：

一是 CPU 绑定不一致。跑压力测试时建议用taskset绑核，避免调度抖动。

Linux 下绑核示例：

taskset -c 0-3 erl -noshell -s stress run 100000 100 -s init stop

二是启动参数不一致。SMP 开启数量、进程数上限、最大原子数都会影响性能，要保持一致。

三是消息大小不一致。如果测试消息是二进制大对象，内存复制策略会显著影响结果；如果只是小原子或小整数，测的更多是调度器吞吐而不是内存复制。建议设计两套测试，一套小消息，一套大二进制。

10. 常见问题与排查方法

11. 最佳实践与使用建议

如果决定深入研究 PON-Beam，这套实践流程可以参考。

先从原生 Erlang 源码构建开始。不要一上来就编译 PON-Beam，先在相同环境把官方 OTP 跑通。因为你需要一个对比基线。环境差异越小，后面针对 VM 改动做的测量就越可信。

然后架构层面的阅读顺序建议是：消息发送模块 -> 进程调度模块 -> 订阅表相关模块。如果不是很熟悉 BEAM 源码，可以先从erl_process.c里找send相关函数，沿着消息路径读下去。读的时候重点关注：消息是从哪里进入接收方队列的，进程什么时候被标记为可运行，有没有专门的事件触发函数。

再然后设计一个最小实验用例，只验证一个功能点。比如“订阅一个事件，某个进程能否在事件发生后的极短时间内被调度执行”。这个用例要能在原生 BEAM 和 PON-Beam 上都运行，便于对比。

实验数据的记录要规范化。每次跑测试记录这些信息：

• 机器 CPU 型号和核数。
• Erlang 版本号或源码 commit id。
• 编译参数。
• 启动参数。
• 测试负载参数。
• 测试耗时和内存峰值。
• 运行的次数和方差。

跑完测试不要急着下结论。先看看结果是否稳定，多跑几次，排除偶发因素。如果 PON-Beam 在某类负载上表现不一样，再进一步分析是订阅表降低了消息匹配成本，还是调度路径发生了变化。

12. 总结与下一步

这次的 PON-Beam 虽然只是一个围绕 Erlang VM 的实验性方向，但它提供了一个非常有价值的思考角度：BEAM 的消息机制不是唯一的并发模型实现方案，Actor 模型也不一定非得靠邮箱扫描来完成消息匹配。

如果你对 Erlang 内部机制感兴趣，最值得先做的一件事是把官方 BEAM 源码拉到本地，找到send和receive的执行路径，理解原生实现之后，再去看 PON-Beam 改了什么。如果 PON-Beam 暂时拿不到源码，那至少要理解清楚原生 BEAM 的消息路径和调度触发逻辑，这对后续做任何 Erlang 性能调优都有帮助。

最容易踩的坑有两个：一是不看版本和环境就盲目对比，得出错误的性能结论；二是过于期待实验性项目直接可用于生产。PON-Beam 这类项目的目标是验证概念，不是替代 OTP，这一点要摆正预期。

需要提醒的是，Erlang 生态的工具链、调试器、第三方库都围绕原生 BEAM 构建。你在 PON-Beam 上做的实验成果，更实际的价值是反过来加深对原生 BEAM 的理解，而不是立即迁移到业务系统里。如果实验过程中积累了一些可复用的测试脚本和基准数据，建议整理成一套完整的测试工程，方便后续拿到新版代码时回归验证。这样等 PON-Beam 后续发布更完整的实现时，你就能第一时间验证它到底有没有解决 BEAM 在消息路径上的那些老问题。