C++和Rust_后端程序員一定要看的語言大比拼：Java vs. Go vs. Rust

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

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

Web服務提供的服務端點

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

編譯后的二進制文件尺寸

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

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

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

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

內存使用情況

空閑狀態

每個應用程序在內存空閑時的內存使用情況

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

服務REST請求

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

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個打開的連接，并重復調用GET端點，持續30秒。這里我僅使用兩個線程，因為wrk和被測程序都在同一臺計算機上運行，所以我不希望它們在可用資源(尤其是CPU)上相互競爭(太多)。

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

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

/hello

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

/hello端點的CPU使用率

/hello端點的內存使用情況

/hello端點處理的每秒請求數

/greeting/{name}

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

/greeting端點的CPU使用率

/greeting端點的內存使用情況

/greeting端點處理的每秒請求數

/fibonacci/{number}

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

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

/fibonacci端點的CPU使用率

/fibonacci端點的內存使用情況

/fibonacci端點處理的每秒請求數

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

超時時間

/fibonacci端點的延遲

運行時大小

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

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

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

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

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

最終Docker鏡像大小

結論

三種語言的比較

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

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

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

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

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

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

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

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

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

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

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