大家好，我是煎魚。

如果你用 Go 跑服務，大概率會遇到一個老朋（問）友（題）：GOMAXPROCS。他決定了 Go 程序最多同時用多少個線程來跑 goroutine。

在 Go1.24 以及更早版本里，GOMAXPROCS 默認等于宿主機的 CPU 核數。這在裸機場景下沒問題，但放到 Kubernetes / 容器環境里，就可能出大坑。

今天我們聊聊 Go1.25 帶來的這一點新變化。Go 官方博客為此還寫了篇技術文章來推廣本次的容器感知的 GOMAXPROCS 默認值變化：

圖片

為什么要改？

Go1.25 以前的舊邏輯：

• 宿主機有 128 核 → Go 默認 GOMAXPROCS=128；
• 容器只給了你 2 核；
• Go 程序還是傻乎乎用滿 128 核 → 結果觸發 CPU throttling。

問題在于限流代價很高：

• 內核不是平滑限制，而是直接 暫停進程一整段時間（默認 100ms）；
• 對延遲敏感的服務，直接爆炸。

新的默認行為

Go1.25 起，Runtime（運行時）會自動檢測容器的 CPU limit：

• 如果 limit < 宿主機核數，默認設為 limit；
• 并且會 定期檢查 limit 是否變化，動態更新 GOMAXPROCS；
• 如果你手動設置了 GOMAXPROCS，還是以你為準。

一句話：Go 終于開箱即用，更貼合容器實際資源。

一個直觀的例子

宿主機 16 核，Pod 配置：

resources:
  limits:
    cpu: "2"

在以前的 Go 1.24：

fmt.Println(runtime.GOMAXPROCS(0)) // 輸出 16

由于 CPU 超配，導致 throttling，容易出現延遲飆升。

在新版本 Go1.25 及以后：

fmt.Println(runtime.GOMAXPROCS(0)) // 輸出 2

能夠完美貼合 limit，運行較為穩定。

K8s 云原生場景

CPU request 是否有影響

K8s 里還有 CPU request，但它不是硬限制：

• 超過 request，只會在機器緊張時被 “降權”，不會直接 throttling；
• 所以 Go 不能用 request 作為依據。

是否需要手動設 CPU limit

不一定，看我們的使用目標：

• 如果追求資源利用率 → 不設 limit，容器能吃多少吃多少。但很容易在節點資源不足時打爆節點。
• 如果追求延遲穩定性 → 設 limit，避免超配被限流。大部分都會設置。
• 最糟糕情況：2 核容器跑在 128 核機器上但沒設 limit → 還會被 Go 當 128 核處理 → 這時候要么設 limit，要么手動調 GOMAXPROCS。

代碼例子

一個最小示例：

package main

import (
    "fmt"
    "runtime"
)

func main() {
    fmt.Println("GOMAXPROCS =", runtime.GOMAXPROCS(0))
}

在容器里運行：

# 宿主機 16 核，容器限 2 核
docker run --cpus=2 myapp

輸出：

GOMAXPROCS = 2

升級到 Go 1.25 后，默認就是這樣的效果。

模型差異：并行度 vs 吞吐量

這里要注意：

• GOMAXPROCS 控制的是 并行度：同時跑多少線程；
• 容器 CPU limit 控制的是 吞吐量：每 100ms 能用多少 CPU 時間。

例子：

• 2 CPU limit = 每 100ms 總共能用 200ms CPU；
• 可以是 2 線程跑滿，也可以 4 線程各跑 50ms。

Go 的策略是 取整向上（比如 2.5 → GOMAXPROCS=3），保證盡量跑滿。

總結

Go1.25 的容器感知 GOMAXPROCS 帶來了更靈活的默認行為，使其在云原生環境更加高效：

• 避免 CPU throttling，降低尾延遲；
• 動態適配容器 limit；
• 讓 Go 服務更適合跑在 Kubernetes 等平臺。

一句話：以后寫 Go 服務，不用再手動裝 automaxprocs，官方自帶了。

Go1.25 起做到了開箱即用，更適合云原生環境了！