這是Java，Go和Rust之間的比較。這不是基準測試，更多是對可執(zhí)行文件大小、內(nèi)存使用率、CPU使用率、運行時要求等的比較，當然還有一個小的基準測試，可以看到每秒處理的請求數(shù)量，我將嘗試對這些數(shù)字進行有意義的解讀。

為了嘗試將蘋果與蘋果進行比較(也許是？)，我在此比較中使用每種語言編寫了一個Web服務。Web服務非常簡單，它提供了三個REST服務端點(endpoint)。

Web服務提供的服務端點

這三個Web服務的代碼倉庫托管在github上。

編譯后的二進制文件尺寸

有關如何構建二進制文件的一些信息。對于Java，我使用maven-shade-plugin和mvn package命令將所有內(nèi)容構建到一個大的jar中。對于Go，我使用go build。最后，我使用了cargo build --release構建Rust服務的二進制文件。

每個程序的大小(以兆字節(jié)為單位)

編譯后的文件大小還取決于所選的庫/依賴項，因此，如果依賴項的身軀臃腫，則編譯后的程序也將難以幸免。在我的特定情況下，針對我選擇的特定庫，以上是程序編譯后的大小。

在后續(xù)的一個單獨小節(jié)中，我會把這三個程序都構建并打包為docker鏡像，并列出它們的大小，以顯示每種語言所需的運行時開銷。下面有更多詳細信息。

內(nèi)存使用情況

空閑狀態(tài)

每個應用程序在內(nèi)存空閑時的內(nèi)存使用情況

什么？Go和Rust版本顯示空閑時內(nèi)存占用量的條形圖在哪里？好了，它們在那里，只有JVM啟動的程序在空閑狀態(tài)時消耗160 MB以上的內(nèi)存，它什么也沒做。Go應用程序僅使用0.86 MB，Rust應用也僅使用了0.36 MB。這是一個巨大的差異！在這里，Java使用的內(nèi)存比Go和Rust應用使用的內(nèi)存高出兩個數(shù)量級，只是空占著內(nèi)存卻什么都不做。那是巨大的資源浪費。

服務REST請求

讓我們使用wrk發(fā)起訪問API的請求，并觀察內(nèi)存和CPU使用情況，以及在我的計算機上三個版本程序的每個端點每秒處理的請求數(shù)。

wrk -t2 -c400 -d30s http://127.0.0.1:8080/hello wrk -t2 -c400 -d30s http://127.0.0.1:8080/greeting/Janewrk -t2 -c400 -d30s http://127.0.0.1:8080/fibonacci/35

上面的wrk命令使用兩個線程并在連接池中保持400個打開的連接，并重復調(diào)用GET端點，持續(xù)30秒。這里我僅使用兩個線程，因為wrk和被測程序都在同一臺計算機上運行，所以我不希望它們在可用資源(尤其是CPU)上相互競爭(太多)。

每個Web服務都經(jīng)過單獨測試，并且在每次運行之間都重新啟動了Web服務。

以下是該程序的每個版本的三個運行中的最佳結果。

• /hello

該端點返回Hello，World！信息。它分配字符串“ Hello，World！” 并將其序列化并以JSON格式返回。

/hello端點的CPU使用率

/hello端點的內(nèi)存使用情況

/hello端點處理的每秒請求數(shù)

• /greeting/{name}

該端點接受一個段路徑參數(shù){name}，然后格式化字符串“Hello,{name}!”，序列化并以JSON格式的問候消息返回。

/greeting端點的CPU使用率

/greeting端點的內(nèi)存使用情況

/greeting端點處理的每秒請求數(shù)

• /fibonacci/{number}

該端點接受一個段路徑參數(shù){number}，并返回序列化為JSON格式的斐波納契數(shù)和輸入數(shù)。

對于這個特定的端點，我選擇以遞歸形式實現(xiàn)它。我毫不懷疑，迭代實現(xiàn)會產(chǎn)生更好的性能結果，并且出于生產(chǎn)目的，應該選擇一種迭代形式，但是在生產(chǎn)代碼中，有些情況下必須使用遞歸(并非專門用于計算第n個斐波那契數(shù) )。為此，我希望該實現(xiàn)涉及大量CPU棧分配。

/fibonacci端點的CPU使用率

/fibonacci端點的內(nèi)存使用情況

/fibonacci端點處理的每秒請求數(shù)

在Fibonacci端點測試期間，Java是唯一一個有150個請求超時的實現(xiàn)，如下面wrk的輸出所示。

超時時間

/fibonacci端點的延遲

運行時大小

為了模擬現(xiàn)實世界中的云原生應用程序，并避免“它僅可以在我的機器上運行！”，我分別為這三個應用程序創(chuàng)建了一個docker鏡像。

Docker文件的源代碼包含在代碼庫相應程序文件夾下。

作為我使用過的Java應用程序的基礎鏡像，openjdk:8-jre-alpine是已知大小最小的鏡像之一，但是，這附帶了一些警告，這些警告可能適用于您的應用程序，也可能不適用于您的應用程序，主要是alpine鏡像在處理環(huán)境變量名稱方面不是posix兼容的，因此您不能在Dockerfile中使用ENV中的(點)字符(不過這沒什么大不了的)，另一個是alpine Linux鏡像是使用musl libc而不是glibc編譯的，這意味著如果您的應用程序依賴于需要glibc，它可能無法正常工作。不過，在這里，alpine鏡像工作是正常的。

至于應用程序的Go版本和Rust版本，我已經(jīng)對其進行了靜態(tài)編譯，這意味著它們不希望在運行時鏡像中存在libc(glibc，musl…等)，這也意味著它們不需要運行OS的基本鏡像。因此，我使用了scratch docker鏡像，這是一個no-op鏡像，以零開銷托管已編譯的可執(zhí)行文件。

我使用的Docker鏡像的命名約定為{lang}/webservice。該應用程序的Java，Go和Rust版本的鏡像大小分別為113、8.68和4.24 MB。

最終Docker鏡像大小

結論

三種語言的比較

在得出任何結論之前，我想指出這三種語言之間的關系。Java和Go都是支持垃圾回收的語言，但是Java會提前編譯為在JVM上運行的字節(jié)碼。啟動Java應用程序時，JIT編譯器會被調(diào)用以通過將字節(jié)碼編譯為本地代碼來優(yōu)化字節(jié)碼，以提高應用程序的性能。

Go和Rust都提前編譯為本地代碼，并且在運行時不會進行進一步的優(yōu)化。

Java和Go都是支持垃圾收集的語言，具有**STW(停止世界)**的副作用。這意味著，每當垃圾收集器運行時，它將停止應用程序，進行垃圾收集，并在完成后從停止的地方恢復應用程序。大多數(shù)垃圾收集器需要停止運行，但是有些實現(xiàn)似乎不需要這樣做。

當Java語言在90年代創(chuàng)建時，其最大的賣點之一是一次編寫，可在任何地方運行。當時這非常好，因為市場上沒有很多虛擬化解決方案。如今，大多數(shù)CPU支持虛擬化，這種虛擬化抵消了使用某種語言進行開發(fā)的誘惑(該語言承諾可以運行在任何平臺上)。Docker和其他解決方案以更為低廉的代價提供虛擬化。

在整個測試中，應用程序的Java版本比Go或Rust對應版本消耗了更多的內(nèi)存，在前兩個測試中，Java使用的內(nèi)存大約增加了8000％。這意味著對于實際應用程序，Java應用程序的運行成本會更高。

對于前兩個測試，Go應用程序使用的CPU比Java少20％，同時處理比java版多出38％的請求。另一方面，Rust版本使用的CPU比Go減少了57％，而處理的請求卻增加了13％。

第三次測試在設計上是占用大量CPU的資源，因此我想從中擠出CPU的每一分。Go和Rust都比Java多使用了1％的CPU。而且我認為，如果wrk不是在同一臺計算機上運行，那么這三個版本都會使CPU達到100%的上限值。在內(nèi)存方面，Java使用的內(nèi)存比Go和Rust多2000％。Java可以處理的請求比Go多出20％，而Rust可以處理的請求比Java多出15％。

在撰寫本文時，Java編程語言已經(jīng)存在了將近30年，這使得在市場上尋找Java開發(fā)人員變得相對容易。另一方面，Go和Rust都是相對較新的語言，因此與Java相比，自然而然的開發(fā)人員的數(shù)量更少些。不過，Go和Rust都擁有很大的吸引力，許多開發(fā)人員正在將它們用于新項目，并且有許多使用Go和Rust的生產(chǎn)中正在運行的項目，因為簡單地說，就資源而言，它們比Java更有效。

在編寫本文的程序時，我同時學習了Go和Rust。就我而言，Go的學習曲線很短，因為它是一種相對容易掌握的語言，并且與其他語言相比語法很小。我只用了幾天就用Go編寫了程序。關于Go需要注意的一件事是編譯速度，我不得不承認，與Java/C/C++/Rust等其他語言相比，它的速度非常快。該程序的Rust版本花了我大約一個星期的時間來完成，我不得不說，大部分時間都花在弄清borrow checker向我要什么上。Rust具有嚴格的所有權規(guī)則，但是一旦掌握了Rust的所有權和借用概念，編譯器錯誤消息就會突然變得更加有意義。違反借閱檢查規(guī)則時，Rust編譯器對您大吼的原因是因為編譯器希望在編譯時證明已分配內(nèi)存的壽命和所有權。這樣做可以保證程序的安全性(例如：沒有懸掛的指針，除非使用了不安全(unsafe)的代碼逃離檢查)，并且在編譯時確定了釋放位置，從而消除了垃圾收集器的需求和運行時成本。當然，這是以學習Rust的所有權系統(tǒng)為代價的。

在競爭方面，我認為Go是Java(通常是JVM語言)的直接競爭對手，但不是Rust的競爭對手。另一方面，Rust是Java，Go，C和C ++的重要競爭對手。

由于他們的效率，我看到了自己將會在Go和Rust中編寫更多的程序，但是很可能在Rust中編寫更多的程序。兩者都非常適合Web服務，CLI，系統(tǒng)程序(…etc)開發(fā)。但是，Rust比Go具有根本優(yōu)勢。它不是垃圾收集的語言，與C和C++相比，它可以安全地編寫代碼。例如，Go并不是特別適合用于編寫OS內(nèi)核，而這里又是Rust的亮點，并與C/C ++競爭，因為它們是使用OS編寫的長期存在和事實上的語言。Rust與C/C++競爭的另一種方式在嵌入式世界中，我將繼續(xù)進行討論。

總結

以上是生活随笔為你收集整理的C++和Rust_后端程序员一定要看的语言大比拼：Java vs. Go vs. Rust的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。