不同语言运行 100 万个并发任务需要多少内存？

大家好，我是猫哥。在前几天的《Python潮流周刊#5：并发一百万个任务要用多少内存？》中，我分享了一篇同题文章，在发布后，我才发现有人已翻译了它，特此分享这篇译文。值得注意的是，译者在文末还翻译了几则评论内容，以及指出了原文的不足之处。

译者：InCerry

译文：https://www.cnblogs.com/InCerry/p/memory-consumption-of-async.html

原文：https://pkolaczk.github.io/memory-consumption-of-async

Github代码：https://github.com/pkolaczk/async-runtimes-benchmarks

正文

在这篇博客文章中，我深入探讨了异步和多线程编程在内存消耗方面的比较，跨足了如 Rust、Go、Java、C#、Python、Node.js 和 Elixir 等流行语言。

不久前，我不得不对几个计算机程序进行性能比较，这些程序旨在处理大量的网络连接。我发现那些程序在内存消耗方面有巨大的差异，甚至超过 20 倍。有些程序在 10000 个连接中仅消耗了略高于 100MB 的内存，但另一些程序却达到了接近 3GB。

不幸的是，这些程序相当复杂，功能也不尽相同，因此很难直接进行比较并得出有意义的结论，因为这不是一个典型的苹果到苹果的比较。这促使我想出了创建一个综合性基准测试的想法。

基准测试

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

启动 N 个并发任务，每个任务等待 10 秒钟，然后在所有任务完成后程序就退出。任务的数量由命令行参数控制。

在 ChatGPT 的小小帮助下，我可以在几分钟内用各种编程语言编写出这样的程序，甚至包括那些我不是每天都在用的编程语言。为了方便起见，所有基准测试代码都可以在我的 GitHub 上找到。

Rust

我用 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，一个使用 tokio，另一个使用 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

在 Go 语言中，goroutine 是实现并发的基本构建块。我们不需要分开等待它们，而是使用 WaitGroup 来代替：

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

Java 传统上使用线程，但 JDK 21 提供了虚拟线程的预览，这是一个类似于 goroutine 的概念。因此，我创建了两个版本的基准测试。我也很好奇 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 类似，C# 对 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

下面是 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

还有 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

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
• Rust: 1.69
• Go: 1.18.1
• Java: OpenJDK “21-ea” build 21-ea+22-1890
• .NET: 6.0.116
• Node.JS: v12.22.9
• Python: 3.10.6
• Elixir: Erlang/OTP 24 erts-12.2.1, Elixir 1.12.2

所有程序在可用的情况下都使用发布模式（release mode）进行运行。其他选项保持为默认设置。

结果

最小内存占用

让我们从一些小的任务开始。因为某些运行时需要为自己分配一些内存，所以我们首先只启动一个任务。

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

我们可以看到，这些程序确实分为两组。Go 和 Rust 程序，静态编译为本地可执行文件，需要很少的内存。其他在托管平台上运行或通过解释器消耗更多内存的程序，尽管在这种情况下 Python 表现得相当好。这两组之间的内存消耗差距大约有一个数量级。

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

10k 任务

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

这里有一些意外发现！大家可能都预计线程将成为这个基准测试的大输家。这对于 Java 线程确实如此，实际上它们消耗了将近 250MB 的内存。但是从 Rust 中使用的原生 Linux 线程似乎足够轻量级，在 10000 个线程时，内存消耗仍然低于许多其他运行时的空闲内存消耗。异步任务或虚拟（绿色）线程可能比原生线程更轻，但我们在只有 10000 个任务时看不到这种优势。我们需要更多的任务。

另一个意外之处是 Go。Goroutines 应该非常轻量，但实际上，它们消耗的内存超过了 Rust 线程所需的 50%。坦率地说，我本以为 Go 的优势会更大。因此，我认为在 10000 个并发任务中，线程仍然是相当有竞争力的替代方案。Linux 内核在这方面肯定做得很好。

Go 也失去了它在上一个基准测试中相对于Rust异步所占据的微小优势，现在它比最好的 Rust 程序消耗的内存多出6倍以上。它还被 Python 超越。

最后一个意外之处是，在 10000 个任务时，.NET 的内存消耗并没有从空闲内存使用中显著增加。可能它只是使用了预分配的内存。或者它的空闲内存使用如此高，10000 个任务太少以至于不重要。

100k  任务

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

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

而 Linux .NET 可能有作弊，因为它的内存使用仍然没有增加。😉 我不得不仔细检查一下是否确实启动了正确数量的任务，果然，它确实做到了。而且它在大约 10 秒后仍然可以退出，所以它没有阻塞主循环。神奇！.NET干得好。

100 万任务

现在我们来试试极限场景。

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

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

终于我们看到了 C# 程序内存消耗的增加。但它仍然非常具有竞争力。它甚至成功地稍稍击败了 Rust 的一个运行时！

Go 与其他程序之间的差距扩大了。现在 Go 在胜利者面前输掉了超过 12 + 倍。它还输给了 Java 2 倍以上，这与人们普遍认为 JVM 是内存大户，而 Go 轻量的观念相矛盾。

Rust 的 tokio 依然无可匹敌。在看过它在 100k 任务下的表现后，这并不令人惊讶。

最后的话

正如我们观察到的，大量的并发任务可能会消耗大量的内存，即使它们不执行复杂的操作。不同的编程语言运行时具有不同的取舍，有些在少量任务中表现轻量和高效，但在数十万个任务中的扩展性表现差。相反，其他一些具有高初始开销的运行时可以毫不费力地应对高负载。值得注意的是，并非所有运行时都能在默认设置下处理大量的并发任务。

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

评论区

评论区也有很多大佬给出了建议，比较有意思，所以也翻译了放在下方

JB-Dev

在 C# 实现中，你不需要调用Task.Run(...)。这会增加第二个任务延续的开销。

在没有额外开销的情况下，我观察到 1M 基准测试的内存使用量减少了一半以上，从 428MB 降到 183MB（代码在这里：https://github.com/J-Bax/CS...

例如，不要使用Task.Run(...)而是这样做：

tasks.Add(Task.Delay(TimeSpan.FromMilliseconds(delayMillisec)));

Christoph Berger

Go 的结果并不特别令人惊讶。

每个 goroutine 开始时的预分配栈为 2KiB，所以一百万个 goroutine 消耗大约 2GB（2,048 * 1,000,000 字节）。

这与我使用 go build&& /usr/bin/time -l ./goroutinememorybenchmark 运行测试代码时得到的数字非常接近：

2044968960 的最大常驻集大小

（我不确定图中的 2,658 GB 是如何测量出来的，但数量级是相同的。）

毫无疑问，为每个 goroutine 预分配一个栈使 Go 在与那些在真正需要时才分配任何线程本地内存的并发系统的语言相比处于劣势。（附注：在这特定的上下文中，我将“线程”作为绿色或虚拟线程和 goroutine 的同义词。）

我想，在线程做有实质性工作的测试中，各种语言之间的差异可能会大大缩小。

D. Christoph Berge

我不完全了解后面发生了什么，但对于 1000 个 Goroutine，Go 只消耗每个 goroutine 约 300 字节。只有当它增加到每个 3000 Goroutine 时，它才开始每个 Goroutine 使用 2KB。

Berger D.

你是如何得到这些测量结果的？

不幸的是，我无法复制你的发现。

为了获得较小数量的 goroutine 的更准确结果，我决定在每次测试运行结束后读取runtime.MemStats.StackInuse。

结果：

所有 1000 个 goroutines 完成。StackInuse：2,359,296（每个 goroutine 2KB） 

所有 3000 个 goroutines 完成。StackInuse：6,586,368（每个 goroutine 2KB） 

所有 10000 个 goroutines 完成。StackInuse：21,037,056（每个 goroutine 2KB） 

所有 100000 个 goroutines 完成。StackInuse：205,127,680（每个 goroutine 2KB） 

所有 1000000 个 goroutines 完成。StackInuse：2,048,622,592（每个 goroutine 2KB）

Witek

对于 Elixir / Erlang，默认进程限制为 32k pids。可以通过解释器标志将其增加到 20 亿。例如：erl +P 4000000，我编写了一个小的 Erlang 程序来做你所做的事情（但确保在循环中不分配不必要的内存），并且在 1 百万个进程中峰值 RSS 使用量为 2.7GiB。然而，这仍然非常人工和合成。Erlang 默认为每个进程分配额外的堆，因为在现实生活中，您实际上会在进程中执行一些操作并需要一点内存，因此预先分配比以后分配更快。如果您真的想在这个愚蠢的基准测试中减少内存使用量，您可以传递选项以 spawn_opt，或使用自定义 +h 选项启动解释器，例如。+h 10，或者 +hms10（默认值为 〜356）。这将将峰值 RSS 使用率从 2.7 GiB 降低到 1.1 GiB。

译者注

本文比较了各个语言开启 N 个任务需要多少内存，如作者所说，这是一个很难去比较的东西，可以看到作者也已经尽力了，虽然不是那么严谨，但是也值得一看。

代码上有一些小问题，比如 C# 用的还没有用上 .NET7.0 版本，代码中 Task.Run() 完全是多余的，相较于其它语言多跑了两倍异步任务，修改这些后内存可以降低五分之三，另外配置用的默认配置，并没有发挥各个语言各自最大的优势，比如 C# 一开始默认预分配了 100MB 内存，另外 Java 等也没有设置对应的 GCHeap 参数来控制内存。

总得来说 C# 的表现是非常亮眼的，在本次的 100 万任务测试中排名第二，仅仅落后于使用 tokio 的 Rust，可见 C# 在高并发多任务等网络编程上还是有很大的优势。

End

欢迎大家加入【ChatGPT&AI 变现圈】，零门槛掌握 AI 神器！我们带你从小白到高手，解锁智能问答、自动化创作、技术变现的无限可能。与我们共同成长，开启 AI 新征程！立即行动，未来已来！（详情请戳：知识星球：ChatGPT&AI 变现圈，正式上线！）

点个在看你最好看