Zig并发与Erlang并发对比：Zig效率更低吗？

你的测试结果差异本质上是两种完全不同的并发模型导致的，再加上测试用例本身的设计偏差，具体原因拆解如下：

1. 并发模型的核心区别 #

• Erlang进程：用户态轻量执行单元
  Erlang的spawn创建的是BEAM虚拟机管理的轻量进程（也叫绿程/用户态线程），属于M:N调度模型：多个用户态进程由BEAM的用户态调度器管理，映射到少量OS内核线程执行。

  • 上下文切换在用户态完成，不需要陷入内核，开销仅为OS线程切换的1/50~1/100；
  • 每个轻量进程初始栈仅几KB，且支持动态扩容，内存开销极低，轻松支撑百万级进程。

• Zig线程：OS内核线程
  Zig的std.Thread.spawn创建的是操作系统原生线程，属于1:1调度模型：每个线程对应一个OS内核线程，由操作系统内核调度。

  • 上下文切换需要内核参与，涉及寄存器保存、地址空间切换、调度队列维护等操作，开销极大；
  • 每个OS线程默认栈大小为MB级（如Linux下通常8MB），启动10万个线程就需要约80GB内存，内存分配和回收的成本极高。

2. 测试用例的不公平性 #

你的测试代码存在明显的设计偏差，放大了结果差异：

• Erlang代码是批量启动200万个轻量进程，无需等待每个进程结束（进程执行完disp()就自动退出），BEAM调度器可以并行调度这些进程，充分利用并发优势；
• Zig代码是串行启动并等待每个线程完成（启动一个线程就调用t.join()），相当于单线程串行执行，完全没有利用多线程的并发能力，这是Zig耗时远高于Erlang的关键原因之一。

如果修正Zig的测试代码，改为批量启动线程后统一等待，比如：

//!Zig
const std = @import("std");

pub fn main() !void{
    var threads = std.ArrayList(std.Thread).init(std.heap.page_allocator);
    defer threads.deinit();

    for(0..100000) |_|{
        const t = try std.Thread.spawn(.{}, disp, .{});
        try threads.append(t);
    }

    for(threads.items) |t|{
        t.join();
    }

    std.debug.print("done", .{});
}

fn disp() void{
    _ = 10;
}

即使这样，Zig的耗时依然会显著高于Erlang，因为OS线程的创建和调度开销远大于Erlang轻量进程。

3. 适用场景差异 #

• Erlang的轻量进程模型专为高并发、分布式、容错场景设计，适合处理大量细粒度的IO密集型任务（如网络服务）；
• Zig的OS线程模型更贴近底层，适合CPU密集型任务或需要直接操作系统资源的场景，优势在于性能可控、底层访问能力强，但不适合百万级别的细粒度并发。

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