Go 單機能創建多少個 Goroutine

    Go 語言以其顯著的併發性能和輕量級的線程模型而聞名。Goroutine，作爲 Go 語言中實現併發的主要手段，允許開發人員編寫高效且併發的代碼。那麼，在 Go 單機上究竟能創建多少個 Goroutine 呢？下面我們來一起分析分析。

前置

    首先我們來計算一個 Goroutine 的大小。Go 語言中 Goroutine 的堆棧初始大小，在早期的版本中是 4KB。然而，在後續的更新中，出於對內存使用的優化考慮，Go 團隊將其降低到了 2KB。

這裏的 2KB 和 4KB 是 Goroutine 初始堆棧大小的典型值，它們並不是在不同操作系統或硬件平臺下的區別，而是 Go 語言在不同版本中對 Goroutine 內存管理策略優化的結果。

需要注意的是，無論 Goroutine 的初始堆棧大小是 2KB 還是 4KB，其大小都是可以動態改變的。那這裏我們假設在極限情況下一個 Goroutine 的大小爲 2KB。

    其次，在今天的計算環境中，一般的單機配置通常包括一個具有四個處理器核心的 CPU 和 8GB 的系統內存。這樣的配置既可以滿足絕大多數日常應用的需求，也能應對一些較爲複雜、需要較高計算能力的任務。 在一臺典型的單機服務器上，擁有四個處理器核心和 8GB 的內存。然而，並非所有的 8GB 內存都可用於運行程序。

操作系統本身就需要一部分內存來進行各項操作，比如系統進程、內核操作等，具體的數字會因操作系統的不同而不同，但通常會佔用 1-2GB 的內存。因此，可供程序使用的內存通常會少於服務器的總內存。在這種情況下，我們可以大致估算出剩餘的內存大約在 6GB 左右。

分析

  接着我們就可以得出結算，在一臺 4 核 8G 的服務器下，能夠創建的 Goroutine 數量爲：

    總內存（字節） / Goroutine大小（字節）
    首先，我們需要將內存的單位統一。1GB等於1,073,741,824字節（或者1024 * 1024 * 1024字節），1KB等於1024字節。
    因此，6GB的內存等於6 * 1,073,741,824字節，Goroutine的大小爲2 * 1024字節。
    將這些值代入公式，可得：
    (6 * 1,073,741,824) / (2 * 1024) ≈ 3,145,728

  因此，理論上我們能創建大約 314 萬個 Goroutine。但是真的能夠創建這麼多嗎？還有沒有一些 Go 限制的因素的影響？

  實際上，單機能創建的 Goroutine 數量取決於系統資源（內存和 CPU），沒有硬性限制。然而在實際應用中，創建大量 Goroutine 雖然可能，但往往並不推薦，因爲過多的 Goroutine 會導致 CPU 切換上下文的消耗過大，從而影響程序性能。同時，如果 Goroutine 之間需要進行大量的通信和同步，也會帶來一定的性能壓力。再加上 Goroutine 在運行時並非始終保持其初始的堆棧大小。實際上，Go 運行時系統會根據每個 Goroutine 的實際需求動態地調整其堆棧大小。這意味着，如果一個 Goroutine 在運行過程中需要更多的內存空間（例如，由於函數調用深度增加或遞歸操作），Go 運行時系統會自動爲其分配更多的內存。同樣，當這部分內存不再被使用時，Go 還會將其釋放，從而有效地管理內存資源。因此，儘管單個 Goroutine 的初始大小很小，但在高負載或複雜操作的情況下，它可能會佔用更多的內存。這也是爲什麼在實際應用中，可創建的 Goroutine 數量可能會少於理論值的原因。

結論

    在一臺配置有 4 核處理器和 8GB 內存的服務器上，考慮到操作系統及其他運行程序的內存需求，可供 Go 應用使用的內存可能在 6GB 左右。如果每個 Goroutine 的初始大小爲 2KB，根據計算，理論上我們可以創建約 314 萬個 Goroutine。

    但是在實際應用中，Go 程序的併發性能並不完全依賴於創建儘可能多的 Goroutine，更重要的是如何在保持系統穩定性的前提下，充分利用系統的併發能力。因此，儘管理論上在 4 核 8G 的硬件條件下可以創建數百萬個 Goroutine，但在實踐中，我們可能只會創建幾百到幾千個 Goroutine。

    這是因爲，創建大量的 Goroutine 不僅可能導致不必要的內存壓力，還可能增加 CPU 的調度負擔，降低系統整體性能。另外，更多的 Goroutine 也意味着更多的併發管理和同步問題，這可能使得代碼更加複雜，更難以維護。

    因此，在設計 Go 應用時，我們通常會根據任務的實際併發需求，以及服務器的性能和內存狀況，適度地創建和管理 Goroutine，以此來達到最佳的性能和資源使用效率。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/GFM7mvJhsDFgtXCrn435Yg

猜你喜歡