雖然Rust和Go都是從上一代編程語言的錯(cuò)誤中吸取教訓(xùn)的現(xiàn)代編程語言，但它們以完全不同的方式管理并發(fā)，這對(duì)性能和開發(fā)人員體驗(yàn)有巨大的影響。

但首先，我們?yōu)槭裁葱枰l(fā)？

今天，大多數(shù)程序與需要一定時(shí)間才能返回響應(yīng)的資源進(jìn)行交互：例如網(wǎng)絡(luò)或磁盤。如果我們?cè)诘却W(wǎng)絡(luò)響應(yīng)的同時(shí)完全阻塞程序的執(zhí)行，這將是對(duì)硬件的一種相當(dāng)?shù)托У氖褂茫?/p>

這就是為什么Go和Rust在等待I/O(輸入/輸出)時(shí)允許程序執(zhí)行其他任務(wù)的語言特性。

任務(wù)

任務(wù)是可以并發(fā)執(zhí)行的抽象計(jì)算單元：多個(gè)函數(shù)可以(由程序)同時(shí)處理，但它們不一定(由CPU)同時(shí)執(zhí)行(它的并行性需要多個(gè)線程)。

可以使用go關(guān)鍵字在Go中生成新任務(wù)：

go doSomething()
go doAnotherThing()

在Rust中，需要使用spawn函數(shù)：

tokio::spawn(async move {
     do_something().await
});

tokio::spawn(async move {
     do_another_thing().await
});

在這兩種情況下，任務(wù)都由語言的運(yùn)行時(shí)同時(shí)處理。

運(yùn)行時(shí)

運(yùn)行時(shí)的目的是管理和調(diào)度不同的任務(wù)，以便有效地使用硬件。

圖片

Rust和Go的第一個(gè)不同之處。你不能改變Go運(yùn)行時(shí)(除非你使用一個(gè)完全不同的編譯器，比如tinygo)，它是內(nèi)置在語言中的，而在Rust中，語言沒有提供運(yùn)行時(shí)，你必須自己配置。

函數(shù)在等待某些東西(例如網(wǎng)絡(luò))時(shí)將控制權(quán)交還給運(yùn)行時(shí)。在Go中，這是由標(biāo)準(zhǔn)庫、語言和編譯器自動(dòng)完成的，而在Rust中，它在到達(dá)await關(guān)鍵字時(shí)發(fā)生。

Stackfull協(xié)程

Stackfull協(xié)程又稱綠線程，或M:N線程(M個(gè)綠線程運(yùn)行在N個(gè)內(nèi)核線程上)是Go采用的并發(fā)模型。

在這個(gè)模型中，運(yùn)行時(shí)管理輕量級(jí)(綠色)線程，并將它們調(diào)度到可用的硬件線程上。與內(nèi)核線程一樣，每個(gè)任務(wù)都有自己的棧，如果需要，可以由運(yùn)行時(shí)增加棧。

stackfull協(xié)程的第一個(gè)問題是，每個(gè)任務(wù)都有自己的棧，這意味著每個(gè)任務(wù)使用較少的內(nèi)存量。從Go 1.22開始，線程程序使用的最小內(nèi)存量是2 KiB，這意味著如果有10,000個(gè)并發(fā)任務(wù)在運(yùn)行，程序?qū)⑹褂弥辽?0 MiB的內(nèi)存。

Stackfull協(xié)程的第二個(gè)問題是，運(yùn)行時(shí)需要完全控制棧布局，這使得與其他語言(如C的FFI)的互操作性變得困難，因?yàn)檫\(yùn)行時(shí)必須在能夠調(diào)用C代碼之前做一些準(zhǔn)備棧的工作。這就是為什么CGO被認(rèn)為是緩慢的(在現(xiàn)實(shí)中，CGO調(diào)用在30到75納秒內(nèi)完成，在我看來這是相當(dāng)快的)。

Stackless協(xié)程

另一方面，Rust采用了無棧協(xié)程方法，其中任務(wù)沒有自己的棧。在Rust中，F(xiàn)uture基本上是實(shí)現(xiàn)Future Trait的簡單結(jié)構(gòu)，其中每個(gè).await調(diào)用鏈被編譯成巨大的狀態(tài)機(jī)。

如果你正在用Python或c#開發(fā)，你可能已經(jīng)知道async/await函數(shù)著色的巨大代價(jià)，其中同步函數(shù)不能調(diào)用async函數(shù)，反之亦然。

這就導(dǎo)致了許多問題，比如導(dǎo)致了生態(tài)系統(tǒng)的碎片化，其中的庫是不可互操作的，很難在程序中使用libA，因?yàn)槟闶褂玫氖莂sync而不是這個(gè)庫，而且還導(dǎo)致了開發(fā)人員的許多錯(cuò)誤，他們阻塞了運(yùn)行時(shí)的事件循環(huán)，降低了系統(tǒng)的性能。

這在Rust中也同樣存在，因?yàn)闃?biāo)準(zhǔn)庫不提供與同步函數(shù)相同的異步函數(shù)(例如read讀取整個(gè)文件)，并且因?yàn)椴煌倪\(yùn)行時(shí)甚至不能相互操作，如果你開始為tokio運(yùn)行時(shí)編寫程序，你將很難將其移植到另一個(gè)運(yùn)行時(shí)。

雖然這些都在Go中得到了解決，在Go中，一切都是同步的，編譯器和運(yùn)行時(shí)在調(diào)用程序員看不見的異步函數(shù)時(shí)自動(dòng)插入等待點(diǎn)，但這是以性能損失(內(nèi)存和CPU)為代價(jià)的。

雖然Rust方法可以最大限度地利用機(jī)器，但它帶來了一個(gè)碎片化的生態(tài)系統(tǒng)，這給Rust的采用帶來了很大的麻煩。