在这篇博文中，我深入研究了 Rust、Go、Java、C#、Python、Node.js 和 Elixir 等流行语言在异步和多线程编程之间的内存消耗比较。

前段时间，我不得不比较一些旨在处理大量网络连接的计算机程序的性能。我看到这些程序的内存消耗存在巨大差异，甚至超过 20 倍。一些程序消耗的内存略多于 100 MB，但其他程序在 10k 连接时几乎达到 3 GB。不幸的是，这些程序非常复杂，而且在功能上也各不相同，因此很难直接比较它们并得出一些有意义的结论，因为这不是一个对等的比较。这让我产生了创建综合基准的想法。

我用各种编程语言创建了以下程序：

让我们启动 N 个并发任务，其中每个任务等待 10 秒，然后在所有任务完成后程序存在。任务的数量由命令行参数控制。

在 ChatGPT 的一点帮助下，我可以在几分钟内编写出这样的程序，即使是使用我不是每天使用的编程语言。为了您的方便，所有基准测试代码都可以在我的 GitHub 上找到。

我用 Rust 创建了 3 个程序。第一个使用传统线程。这是它的核心：

let mut handles = Vec::new();
for _ in 0..num_threads {
    let handle = thread::spawn(|| {
        thread::sleep(Duration::from_secs(10));
    });
    handles.push(handle);
}
for handle in handles {
    handle.join().unwrap();
}

其他两个版本使用 async，一个使用 async，tokio另一个使用 async async-std。这是变体的核心tokio：

let mut tasks = Vec::new();
for _ in 0..num_tasks {
    tasks.push(task::spawn(async {
        time::sleep(Duration::from_secs(10)).await;
    }));
}
for task in tasks {
    task.await.unwrap();
}

变async-std体非常相似，所以我不会在这里引用它。

在 Go 中，goroutines 是并发的构建块。我们不单独等待它们，而是使用 aWaitGroup代替：

var wg sync.WaitGroup
for i := 0; i < numRoutines; i++ {
    wg.Add(1)
    go func() {
        defer wg.Done()
        time.Sleep(10 * time.Second)
    }()
}
wg.Wait()

Java 传统上使用线程，但 JDK 21 提供了虚拟线程的预览，这是与 goroutines 类似的概念。因此，我创建了基准测试的两个变体。我也很好奇 Java 线程与 Rust 的线程相比如何。

List<Thread> threads = new ArrayList<>();
for (int i = 0; i < numTasks; i++) {
    Thread thread = new Thread(() -> {
        try {
            Thread.sleep(Duration.ofSeconds(10));
        } catch (InterruptedException e) {
        }
    });
    thread.start();
    threads.add(thread);
}
for (Thread thread : threads) {
    thread.join();
}

这是带有虚拟线程的变体。请注意它是多么相似！几乎一模一样！

List<Thread> threads = new ArrayList<>();
for (int i = 0; i < numTasks; i++) {
    Thread thread = Thread.startVirtualThread(() -> {
        try {
            Thread.sleep(Duration.ofSeconds(10));
        } catch (InterruptedException e) {
        }
    });
    threads.add(thread);
}
for (Thread thread : threads) {
    thread.join();
}

C# 与 Rust 类似，对 async/await 有一流的支持：

List<Task> tasks = new List<Task>();
for (int i = 0; i < numTasks; i++)
{
    Task task = Task.Run(async () =>
    {
        await Task.Delay(TimeSpan.FromSeconds(10));
    });
    tasks.Add(task);
}
await Task.WhenAll(tasks);

Node.JS 也是如此：

const delay = util.promisify(setTimeout);
const tasks = [];

for (let i = 0; i < numTasks; i++) {
    tasks.push(delay(10000);
}

await Promise.all(tasks);

而Python在3.5中加入了async/await，所以我们可以这样写：

async def perform_task():
    await asyncio.sleep(10)


tasks = []

for task_id in range(num_tasks):
    task = asyncio.create_task(perform_task())
    tasks.append(task)

await asyncio.gather(*tasks)

Elixir 也以其异步功能而闻名：

tasks =
    for _ <- 1..num_tasks do
        Task.async(fn ->
            :timer.sleep(10000)
        end)
    end

Task.await_many(tasks, :infinity)

测试环境

硬件：Intel(R) Xeon(R) CPU E3-1505M v6 @ 3.00GHz
操作系统：Ubuntu 22.04 LTS，Linux p5520 5.15.0-72-generic
生锈：1.69
去：1.18.1
Java：OpenJDK“21-ea”构建 21-ea+22-1890
.NET：6.0.116
Node.JS：v12.22.9
蟒蛇：3.10.6
Elixir：Erlang/OTP 24 erts-12.2.1，Elixir 1.12.2

如果可用，所有程序都使用发布模式启动。其他选项保持默认。

结果

最小占地面积

让我们从小事做起。由于某些运行时自身需要一些内存，因此我们首先只启动一个任务。

图 1：启动一项任务所需的峰值内存

我们可以看到肯定有两组程序。静态编译为本机二进制文件的 Go 和 Rust 程序需要很少的内存。在托管平台上运行或通过解释器运行的其他程序会消耗更多内存，尽管 Python 在这种情况下表现得非常好。这两组之间的内存消耗大约有一个数量级的差异。

令我惊讶的是 .NET 在某种程度上具有最差的占用空间，但我想这可能可以通过一些设置进行调整。如果有任何技巧，请在评论中告诉我。我没有看到调试和发布模式之间有太大区别。

10k 任务

图 2：启动 10,000 个任务所需的峰值内存

这里有一些惊喜！每个人都可能预料到线程会成为这个基准测试的大输家。Java 线程也是如此，它确实消耗了将近 250 MB 的 RAM。但是从 Rust 使用的原生 Linux 线程似乎足够轻量级，以至于在 10k 线程时内存消耗仍然低于许多其他运行时的空闲内存消耗。异步任务或虚拟（绿色）线程可能比本机线程更轻，但我们不会在只有 10k 任务时看到这种优势。我们需要更多的任务。

另一个惊喜是 Go。Goroutines 应该是非常轻量级的，但实际上它们消耗了 Rust 线程所需 RAM 的 50% 以上。老实说，我原以为 Go 会有更大的不同。因此，我得出结论，在 10k 并发任务时，线程仍然是一个很有竞争力的选择。Linux 内核肯定会在这里做一些事情。

Go 也失去了它在之前的基准测试中相对于 Rust async 的微小优势，现在它消耗的内存比最好的 Rust 程序多 6 倍。它也被Python超越了。

最后的惊喜是，在 10k 任务时，.NET 的内存消耗并没有从空闲内存使用中显着增加。可能它只是使用预分配的内存。或者它的空闲内存使用率如此之高，以至于 10k 任务太少而无关紧要。

100k 任务

我无法在我的系统上启动 100,000 个线程，因此必须排除线程基准测试。可能这可以通过更改系统设置以某种方式进行调整，但尝试了一个小时后我放弃了。所以在 100k 任务时你可能不想使用线程。

图 3：启动 100,000 个任务所需的峰值内存

在这一点上，Go 程序不仅被 Rust 击败，而且被 Java、C# 和 Node.JS 击败。

Linux .NET 可能会作弊，因为它的内存使用量仍然没有增加。;) 我不得不仔细检查它是否真的启动了正确数量的任务，但确实如此。大约 10 秒后它仍然退出，所以它不会阻塞主循环。魔法！干得好，.NET。

100 万个任务

现在让我们走极端。

在 100 万个任务时，Elixir 放弃了** (SystemLimitError) a system limit has been reached. 编辑：一些评论者指出我可以增加进程限制。在调用中添加 --erl '+P 1000000'参数后elixir，它运行良好。

图 4：启动 100 万个任务所需的峰值内存

最后我们看到了 C# 程序内存消耗的增加。但它仍然非常有竞争力。它甚至设法略微击败了 Rust 运行时之一！

Go 和其他人之间的距离增加了。现在围棋输给了赢家超过 12 倍。它也输给了 Java 超过 2 倍，这与 JVM 是内存大户而 Go 是轻量级的普遍看法相矛盾。

Rusttokio仍然是无与伦比的。在看到它在 100k 任务中的表现后，这并不奇怪。

最后一句话

正如我们所观察到的，大量并发任务会消耗大量内存，即使它们不执行复杂的操作也是如此。不同的语言运行时有不同的权衡，有些运行时对于少量任务来说是轻量级和高效的，但对于数十万个任务来说扩展性很差。相反，其他具有高初始开销的运行时可以毫不费力地处理高工作负载。重要的是要注意，并非所有运行时都能够使用默认设置处理大量并发任务。

这种比较只关注内存消耗，而任务启动时间和通信速度等其他因素同样重要。值得注意的是，在 100 万个任务时，我观察到启动任务的开销变得明显，大多数程序需要超过 12 秒才能完成。请继续关注即将推出的基准测试，我将在其中深入探讨其他方面。