你需要多少内存来运行100万个并发任务？

最近，小哈在带小伙伴做前后端分离博客项目，手摸手教学，后端 + 前端全栈开发，从 0 到 1 手敲，1v1 答疑，直到项目上线，后续还会上新更多项目，戳我加入

[原文作者]：Piotr Kołaczkowski

[原文地址]：点击阅读原文

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

不久前，我不得不比较几个设计用于处理大量网络连接的计算机程序的性能。我看到这些程序在内存消耗上有巨大的差异，甚至超过了 20 倍。有些程序只消耗了略超过 100 MB的内存，但其他程序在 10k 连接时几乎达到了 3 GB。不幸的是，这些程序都相当复杂，并且在功能上也有所不同，所以直接比较它们并得出一些有意义的结论将是困难的，因为这将不是一个公平的比较。这让我想到了创建一个合成基准测试的想法。

基准测试

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

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

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

https://github.com/pkolaczk/async-runtimes-benchmarks/tree/main

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 中，goroutines 是并发的构建块。我们不单独等待它们，而是使用 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 提供了虚拟线程的预览，这是一个类似于 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#

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

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 模式启动的。其他选项保持默认。

结果

最小占用

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

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

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

我很惊讶.NET 的占用最差，但我猜这可能可以通过一些设置进行调整。如果有任何技巧，请在评论中告诉我。我没有看到 debug 和 release 模式之间有多大的差异。

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倍以上。

最后一个惊喜是，在10k任务时，.NET 的内存消耗并没有从空闲内存使用中显著增加。可能它只是使用预分配的内存。或者它的空闲内存使用如此之高，以至于10k任务对它来说太少了，不足以有所关系。

100k 任务

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

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

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

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

1 百万任务

现在让我们走到极端。

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

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

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

Go 和其他人之间的距离增加了。现在 Go 输给了冠军超过 12 倍。它也输给了 Java 超过 2 倍，这与 JVM 是内存大户和 Go 是轻量级的一般认知相矛盾。

Rust tokio 仍然无法被击败。在看到它在 100k 任务时的表现后，这并不令人惊讶。

最后的话

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

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

---

👉 欢迎加入小哈的Java项目实战知识星球

，手摸手带你做前后端分离博客项目，手摸手教学，后端 + 前端包办，从 0 到 1 手敲，1v1 答疑，直到项目上线，后续还会上新更多项目。

最近面试BAT，整理一份面试资料《Java面试BATJ通关手册》，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。

获取方式：点“在看”，关注公众号并回复 Java 领取，更多内容陆续奉上。

PS：因公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。

点“在看”支持小哈呀，谢谢啦