來(lái)自：博客園，譯者：InCerry

正文

在這篇博客文章中，我深入探討了異步和多線程編程在內(nèi)存消耗方面的比較，跨足了如Rust、Go、Java、C#、Python、Node.js 和 Elixir等流行語(yǔ)言。

不久前，我不得不對(duì)幾個(gè)計(jì)算機(jī)程序進(jìn)行性能比較，這些程序旨在處理大量的網(wǎng)絡(luò)連接。我發(fā)現(xiàn)那些程序在內(nèi)存消耗方面有巨大的差異，甚至超過(guò)20倍。有些程序在10000個(gè)連接中僅消耗了略高于100MB的內(nèi)存，但另一些程序卻達(dá)到了接近3GB。

不幸的是，這些程序相當(dāng)復(fù)雜，功能也不盡相同，因此很難直接進(jìn)行比較并得出有意義的結(jié)論，因?yàn)檫@不是一個(gè)典型的蘋(píng)果到蘋(píng)果的比較。這促使我想出了創(chuàng)建一個(gè)綜合性基準(zhǔn)測(cè)試的想法。

基準(zhǔn)測(cè)試

我使用各種編程語(yǔ)言創(chuàng)建了以下程序：

啟動(dòng)N個(gè)并發(fā)任務(wù)，每個(gè)任務(wù)等待10秒鐘，然后在所有任務(wù)完成后程序就退出。任務(wù)的數(shù)量由命令行參數(shù)控制。

在ChatGPT的小小幫助下，我可以在幾分鐘內(nèi)用各種編程語(yǔ)言編寫(xiě)出這樣的程序，甚至包括那些我不是每天都在用的編程語(yǔ)言。為了方便起見(jiàn)，所有基準(zhǔn)測(cè)試代碼都可以在我的GitHub上找到。

Rust

我用Rust編寫(xiě)了3個(gè)程序。第一個(gè)程序使用了傳統(tǒng)的線程。以下是它的核心部分：

letmuthandles=Vec::new();
for_in0..num_threads{
lethandle=thread::spawn(||{
thread::from_secs(10));
});
handles.push(handle);
}
forhandleinhandles{
handle.join().unwrap();
}

另外兩個(gè)版本使用了async，一個(gè)使用tokio，另一個(gè)使用async-std。以下是使用tokio的版本的核心部分：

letmuttasks=Vec::new();
for_in0..num_tasks{
tasks.push(task::spawn(async{
time::from_secs(10)).await;
}));
}
fortaskintasks{
task.await.unwrap();
}

async-std版本與此非常相似，因此我在這里就不再引用了。

Go

在Go語(yǔ)言中，goroutine是實(shí)現(xiàn)并發(fā)的基本構(gòu)建塊。我們不需要分開(kāi)等待它們，而是使用WaitGroup來(lái)代替：

varwgsync.WaitGroup
fori:=0;i

	

	Java

	Java傳統(tǒng)上使用線程，但JDK 21提供了虛擬線程的預(yù)覽，這是一個(gè)類似于goroutine的概念。因此，我創(chuàng)建了兩個(gè)版本的基準(zhǔn)測(cè)試。我也很好奇Java線程與Rust線程的比較。

	
Listthreads=newArrayList<>();
for(inti=0;i{
try{
Thread.sleep(Duration.ofSeconds(10));
}catch(InterruptedExceptione){
}
});
thread.start();
threads.add(thread);
}
for(Threadthread:threads){
thread.join();
}



	

	下面是使用虛擬線程的版本。注意看它是多么的相似！幾乎一模一樣！

	
Listthreads=newArrayList<>();
for(inti=0;i{
try{
Thread.sleep(Duration.ofSeconds(10));
}catch(InterruptedExceptione){
}
});
threads.add(thread);
}
for(Threadthread:threads){
thread.join();
}



	

	C#

	與Rust類似，C#對(duì)async/await也有一流的支持：

	
Listtasks=newList();
for(inti=0;i
{
awaitTask.Delay(TimeSpan.FromSeconds(10));
});
tasks.Add(task);
}
awaitTask.WhenAll(tasks);



	

	Node.JS

	下面是 Node.JS:

	
constdelay=util.promisify(setTimeout);
consttasks=[];

for(leti=0;i

	

	Python

	還有Python 3.5版本中加入了async/await，所以可以這樣寫(xiě)：

	
asyncdefperform_task():
awaitasyncio.sleep(10)


tasks=[]

fortask_idinrange(num_tasks):
task=asyncio.create_task(perform_task())
tasks.append(task)

awaitasyncio.gather(*tasks)


	

	Elixir

	Elixir 也因其異步功能而聞名：

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

Task.await_many(tasks,:infinity)

	

	測(cè)試環(huán)境

	硬件: Intel(R) Xeon(R) CPU E3-1505M v6 @ 3.00GHz

	操作系統(tǒng): 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

	所有程序在可用的情況下都使用發(fā)布模式（release mode）進(jìn)行運(yùn)行。其他選項(xiàng)保持為默認(rèn)設(shè)置。

	結(jié)果

	最小內(nèi)存占用

	讓我們從一些小的任務(wù)開(kāi)始。因?yàn)槟承┻\(yùn)行時(shí)需要為自己分配一些內(nèi)存，所以我們首先只啟動(dòng)一個(gè)任務(wù)。

	

	圖1：?jiǎn)?dòng)一個(gè)任務(wù)所需的峰值內(nèi)存

	我們可以看到，這些程序確實(shí)分為兩組。Go和Rust程序，靜態(tài)編譯為本地可執(zhí)行文件，需要很少的內(nèi)存。其他在托管平臺(tái)上運(yùn)行或通過(guò)解釋器消耗更多內(nèi)存的程序，盡管在這種情況下Python表現(xiàn)得相當(dāng)好。這兩組之間的內(nèi)存消耗差距大約有一個(gè)數(shù)量級(jí)。

	讓我感到驚訝的是，.NET某種程度上具有最差的內(nèi)存占用，但我猜這可以通過(guò)某些設(shè)置進(jìn)行調(diào)整。如果有任何技巧，請(qǐng)?jiān)谠u(píng)論中告訴我。在調(diào)試模式和發(fā)布模式之間，我沒(méi)有看到太大的區(qū)別。

	10k 任務(wù)

	

	圖2：?jiǎn)?dòng)10,000個(gè)任務(wù)所需的峰值內(nèi)存

	這里有一些意外發(fā)現(xiàn)！大家可能都預(yù)計(jì)線程將成為這個(gè)基準(zhǔn)測(cè)試的大輸家。這對(duì)于Java線程確實(shí)如此，實(shí)際上它們消耗了將近250MB的內(nèi)存。但是從Rust中使用的原生Linux線程似乎足夠輕量級(jí)，在10000個(gè)線程時(shí)，內(nèi)存消耗仍然低于許多其他運(yùn)行時(shí)的空閑內(nèi)存消耗。異步任務(wù)或虛擬（綠色）線程可能比原生線程更輕，但我們?cè)谥挥?0000個(gè)任務(wù)時(shí)看不到這種優(yōu)勢(shì)。我們需要更多的任務(wù)。

	另一個(gè)意外之處是Go。Goroutines應(yīng)該非常輕量，但實(shí)際上，它們消耗的內(nèi)存超過(guò)了Rust線程所需的50%。坦率地說(shuō)，我本以為Go的優(yōu)勢(shì)會(huì)更大。因此，我認(rèn)為在10000個(gè)并發(fā)任務(wù)中，線程仍然是相當(dāng)有競(jìng)爭(zhēng)力的替代方案。Linux內(nèi)核在這方面肯定做得很好。

	Go也失去了它在上一個(gè)基準(zhǔn)測(cè)試中相對(duì)于Rust異步所占據(jù)的微小優(yōu)勢(shì)，現(xiàn)在它比最好的Rust程序消耗的內(nèi)存多出6倍以上。它還被Python超越。

	最后一個(gè)意外之處是，在10000個(gè)任務(wù)時(shí)，.NET的內(nèi)存消耗并沒(méi)有從空閑內(nèi)存使用中顯著增加?？赡芩皇鞘褂昧祟A(yù)分配的內(nèi)存。或者它的空閑內(nèi)存使用如此高，10000個(gè)任務(wù)太少以至于不重要。

	100k 任務(wù)

	我無(wú)法在我的系統(tǒng)上啟動(dòng)100,000個(gè)線程，所以線程基準(zhǔn)測(cè)試必須被排除?？赡苓@可以通過(guò)某種方式調(diào)整系統(tǒng)設(shè)置來(lái)實(shí)現(xiàn)，但嘗試了一個(gè)小時(shí)后，我放棄了。所以在100,000個(gè)任務(wù)時(shí)，你可能不想使用線程。

	

	在這一點(diǎn)上，Go程序不僅被Rust擊敗，還被Java、C#和Node.JS擊敗。

	而Linux .NET可能有作弊，因?yàn)樗膬?nèi)存使用仍然沒(méi)有增加。 我不得不仔細(xì)檢查一下是否確實(shí)啟動(dòng)了正確數(shù)量的任務(wù)，果然，它確實(shí)做到了。而且它在大約10秒后仍然可以退出，所以它沒(méi)有阻塞主循環(huán)。神奇！.NET干得好。

	100萬(wàn)任務(wù)

	現(xiàn)在我們來(lái)試試極限場(chǎng)景。

	在100萬(wàn)個(gè)任務(wù)時(shí)，Elixir放棄了，提示 ** (SystemLimitError) a system limit has been reached。編輯：有些評(píng)論者指出我可以增加進(jìn)程限制。在elixir啟動(dòng)參數(shù)中添加--erl '+P 1000000'后，它運(yùn)行得很好。

	

	圖4：?jiǎn)?dòng)100萬(wàn)個(gè)任務(wù)所需的峰值內(nèi)存

	終于我們看到了C#程序內(nèi)存消耗的增加。但它仍然非常具有競(jìng)爭(zhēng)力。它甚至成功地稍稍擊敗了Rust的一個(gè)運(yùn)行時(shí)！

	Go與其他程序之間的差距擴(kuò)大了?，F(xiàn)在Go在勝利者面前輸?shù)袅顺^(guò)12倍。它還輸給了Java 2倍以上，這與人們普遍認(rèn)為JVM是內(nèi)存大戶，而Go輕量的觀念相矛盾。

	Rust的tokio依然無(wú)可匹敵。在看過(guò)它在100k任務(wù)下的表現(xiàn)后，這并不令人驚訝。

	最后的話

	正如我們觀察到的，大量的并發(fā)任務(wù)可能會(huì)消耗大量的內(nèi)存，即使它們不執(zhí)行復(fù)雜的操作。不同的編程語(yǔ)言運(yùn)行時(shí)具有不同的取舍，有些在少量任務(wù)中表現(xiàn)輕量和高效，但在數(shù)十萬(wàn)個(gè)任務(wù)中的擴(kuò)展性表現(xiàn)差。相反，其他一些具有高初始開(kāi)銷的運(yùn)行時(shí)可以毫不費(fèi)力地應(yīng)對(duì)高負(fù)載。值得注意的是，并非所有運(yùn)行時(shí)都能在默認(rèn)設(shè)置下處理大量的并發(fā)任務(wù)。

	這個(gè)比較僅關(guān)注內(nèi)存消耗，而任務(wù)啟動(dòng)時(shí)間和通信速度等其他因素同樣重要。值得注意的是，在100萬(wàn)個(gè)任務(wù)時(shí)，我觀察到啟動(dòng)任務(wù)的開(kāi)銷變得明顯，大多數(shù)程序需要超過(guò)12秒才能完成。敬請(qǐng)期待即將到來(lái)的基準(zhǔn)測(cè)試，我將深入探討其他方面。

	評(píng)論區(qū)

	評(píng)論區(qū)也有很多大佬給出了建議，比較有意思，所以也翻譯了放在下方

	JB-Dev

	在C#實(shí)現(xiàn)中，你不需要調(diào)用Task.Run(...)。這會(huì)增加第二個(gè)任務(wù)延續(xù)的開(kāi)銷。

	在沒(méi)有額外開(kāi)銷的情況下，我觀察到1M基準(zhǔn)測(cè)試的內(nèi)存使用量減少了一半以上，從428MB降到183MB（代碼在這里：https://github.com/J-Bax/CS...

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

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

	Christoph Berger

	Go的結(jié)果并不特別令人驚訝。

	每個(gè)goroutine開(kāi)始時(shí)的預(yù)分配棧為2KiB，所以一百萬(wàn)個(gè)goroutine消耗大約2GB（2,048 * 1,000,000字節(jié)）。

	這與我使用go build&& /usr/bin/time -l ./goroutinememorybenchmark運(yùn)行測(cè)試代碼時(shí)得到的數(shù)字非常接近：

	2044968960的最大常駐集大小

	（我不確定圖中的2,658 GB是如何測(cè)量出來(lái)的，但數(shù)量級(jí)是相同的。）

	毫無(wú)疑問(wèn)，為每個(gè)goroutine預(yù)分配一個(gè)棧使Go在與那些在真正需要時(shí)才分配任何線程本地內(nèi)存的并發(fā)系統(tǒng)的語(yǔ)言相比處于劣勢(shì)。（附注：在這特定的上下文中，我將“線程”作為綠色或虛擬線程和goroutine的同義詞。）

	我想，在線程做有實(shí)質(zhì)性工作的測(cè)試中，各種語(yǔ)言之間的差異可能會(huì)大大縮小。

	D. Christoph Berge

	我不完全了解后面發(fā)生了什么，但對(duì)于1000個(gè)Goroutine，Go只消耗每個(gè)goroutine約300字節(jié)。只有當(dāng)它增加到每個(gè)3000 Goroutine時(shí)，它才開(kāi)始每個(gè)Goroutine使用2KB。

	Berger D.

	你是如何得到這些測(cè)量結(jié)果的？

	不幸的是，我無(wú)法復(fù)制你的發(fā)現(xiàn)。

	為了獲得較小數(shù)量的goroutine的更準(zhǔn)確結(jié)果，我決定在每次測(cè)試運(yùn)行結(jié)束后讀取runtime.MemStats.StackInuse。

	結(jié)果：

	所有1000個(gè)goroutines完成。StackInuse：2,359,296（每個(gè)goroutine 2KB）

	所有3000個(gè)goroutines完成。StackInuse：6,586,368（每個(gè)goroutine 2KB）

	所有10000個(gè)goroutines完成。StackInuse：21,037,056（每個(gè)goroutine 2KB）

	所有100000個(gè)goroutines完成。StackInuse：205,127,680（每個(gè)goroutine 2KB）

	所有1000000個(gè)goroutines完成。StackInuse：2,048,622,592（每個(gè)goroutine 2KB）

	Witek

	對(duì)于Elixir / Erlang，默認(rèn)進(jìn)程限制為32k pids?？梢酝ㄟ^(guò)解釋器標(biāo)志將其增加到20億。例如：erl +P 4000000，我編寫(xiě)了一個(gè)小的Erlang程序來(lái)做你所做的事情（但確保在循環(huán)中不分配不必要的內(nèi)存），并且在1百萬(wàn)個(gè)進(jìn)程中峰值RSS使用量為2.7GiB。然而，這仍然非常人工和合成。Erlang默認(rèn)為每個(gè)進(jìn)程分配額外的堆，因?yàn)樵诂F(xiàn)實(shí)生活中，您實(shí)際上會(huì)在進(jìn)程中執(zhí)行一些操作并需要一點(diǎn)內(nèi)存，因此預(yù)先分配比以后分配更快。如果您真的想在這個(gè)愚蠢的基準(zhǔn)測(cè)試中減少內(nèi)存使用量，您可以傳遞選項(xiàng)以spawn_opt，或使用自定義+h選項(xiàng)啟動(dòng)解釋器，例如。+h 10，或者+hms10（默認(rèn)值為?356）。這將將峰值RSS使用率從2.7 GiB降低到1.1 GiB。

	審核編輯：湯梓紅