Go 程式設計面試題：Go 1.25 如何在容器中計算 GOMAXPROCS？

題干

Go 服務執行在 Kubernetes Pod，節點有 64 個邏輯 CPU，但 Pod 的 CPU limit 為 2.5。升級 Go 1.25 後，請解釋預設 GOMAXPROCS 如何變化、它與 CPU request 的關係、cgroup 配額變化是否會更新，以及如何驗證尾延遲、吞吐和 GC。也要說明手動設定 GOMAXPROCS 或 GODEBUG 後哪些自動行為失效。

面試官在考察什麼

題目考察並行執行時、容器資源語意與效能診斷。要區分邏輯 CPU、CPU limit、CPU request、程序 affinity 與 GOMAXPROCS，理解 Go 1.25 讀取 Linux cgroup 平均 CPU 吞吐限制並週期更新，但手動覆蓋會關閉自動更新。只背「設成 2」不足。

先確認這些問題

1. Go 版本、Linux cgroup v1/v2 與容器執行時是什麼？
2. Pod 設定 CPU limit、request，還是兩者都有？limit 會動態調整嗎？
3. 目標是吞吐、P99、GC 暫停還是成本？是否有突發流量？
4. 是否曾以環境變數、啟動參數或程式設定 GOMAXPROCS？

30 秒回答框架

Go 1.25 預設取邏輯 CPU、CPU affinity 與 cgroup 平均 CPU 吞吐限制的較小值；小數配額向上取整，且通常不低於 2，除非硬體或 affinity 少於 2。request 不作為預設依據。接著回答覆蓋優先級、動態更新、觀測驗證與回滾。

逐步拆解方案

1. 理解預設值

未設定 GOMAXPROCS 環境變數且未呼叫 runtime.GOMAXPROCS 時，Go 1.25 Linux 執行時讀取 cgroup CPU quota/period，得到平均吞吐限制，再與邏輯 CPU 和 affinity 取最小值。2.5 CPU 會向上取整為 3。request 是保障權重，不是硬上限，執行時不據此設定預設值。

2. 動態更新與覆蓋優先級

執行時會檢查邏輯 CPU、affinity 或 quota 變化，通常最多每秒更新一次。設定 GOMAXPROCS 環境變數或呼叫 runtime.GOMAXPROCS 會關閉自動更新；runtime.SetDefaultGOMAXPROCS() 可恢復預設。GODEBUG=containermaxprocs=0 禁止讀 cgroup，updatemaxprocs=0 禁止自動更新。

3. 與排程和限流的關係

GOMAXPROCS 是同時執行 Go 使用者程式碼的執行緒上限，不是容器 CPU 用量上限，也不限制阻塞系統呼叫執行緒。值遠高於 limit 會觸發核心 throttle，值過低則可能降低吞吐和 GC 並行度。要與 Kubernetes limit、request 和節點超賣一起分析。

4. 觀測與驗證

記錄啟動時 runtime.GOMAXPROCS(0)、runtime.NumCPU()、affinity、cgroup quota/period 和 GODEBUG。關聯 /sched/gomaxprocs:threads、CPU throttling、run queue、P99、GC CPU fraction、吞吐和錯誤率。quota 變動後確認 GOMAXPROCS 是否跟隨。

5. 負載實驗

固定資料和 Go 版本比較預設值、顯式值與舊版本行為，分別壓測 CPU 密集、I/O 等待與突發短請求。Go 官方指出較低 GOMAXPROCS 可減少 throttle，但尖峰工作負載可能因並行受限而延遲上升，用 P95/P99 與成本共同決策。

6. 上線與回滾

先在固定 limit 的 canary Pod 使用 Go 1.25，設定觀測閘門。若 throttling、P99 或 GC 惡化，可回滾舊映像或設定實驗證明的 GOMAXPROCS；記錄覆蓋會關閉自動更新。移除覆蓋並呼叫 SetDefaultGOMAXPROCS 可恢復預設。

7. 失敗模式與邊界

不要把 request 當 limit、把 runtime.NumCPU() 當可用並行度，或假設所有平台都有 cgroup。非 Linux、沒有 quota、手動 GOMAXPROCS 與舊 Go 版本的行為不同。發布清單記錄 Go 版本、GODEBUG、資源規格和回滾負責人。

合格回答示例

「沒有顯式覆蓋時，Go 1.25 在 Linux 讀 cgroup quota/period，與邏輯 CPU 和 affinity 取最小值；2.5 CPU 向上取整為 3，request 不參與。執行時週期檢查 quota，但環境變數、runtime.GOMAXPROCS 或 GODEBUG=containermaxprocs=0/updatemaxprocs=0 會改變行為。我會記錄 GOMAXPROCS、cgroup、/sched/gomaxprocs、throttling、P99、吞吐和 GC，在 CPU 密集與突發負載比較預設、顯式值和舊版本。canary 超過閾值就回滾，並把自動更新影響寫入手冊。」

常見失分點

• 說 Go 直接使用 CPU request。
• 只把 GOMAXPROCS 設成 limit 整數，忽略小數向上取整。
• 忽略環境變數、程式呼叫與 GODEBUG 會關閉自動更新。
• 只看吞吐，不看 throttle、P99、GC 和突發延遲。
• 把 GOMAXPROCS 當容器 CPU 限額或系統呼叫執行緒上限。

追問方向

2.5 CPU 為何可能是 3？

GOMAXPROCS 必須為正整數，執行時對非整數吞吐限制向上取整，以使用完整配額。

CPU request 為何不參與？

request 是排程與競爭時的軟保障，不能表示穩定硬吞吐上限。

如何確認自動更新？

動態調整 quota，在日誌和 /sched/gomaxprocs:threads 觀察變化，同時核對環境變數與 GODEBUG。

何時手動設定？

工作負載、平台或延遲目標經實驗要求固定並行度時可設定，但要維護回滾配置。

Go 1.24 怎麼辦？

先用顯式值或 cgroup 適配方案過渡，升級 Go 1.25 後重新驗證 limit、affinity 和 throttling。

參考資料

Go 1.25《Release Notes》、Go Blog《Container-aware GOMAXPROCS》與 pkg.go.dev《runtime》文件。