NGINX 1.31.5 加入 Control API 與 Predicate Locations,CppCon 談 C++26 物件常駐,Go 推出 Goroutine 洩漏剖析器
blog.nginx.org · 2026-09-02
NGINX 於 2026 年 9 月 2 日發布 1.31.5 版本,新增 Control API 與 predicate locations 等路由機制;同一天,CppCon 2026 公布 Laurie Kirk 的主題演講預告,討論 C++26 中的物件常駐(object residency)問題;Go 官方部落格也同步刊出文章,介紹 Go 1.27 新增的 goroutine 洩漏剖析器。三則消息分別涉及反向代理設定、語言層級記憶體佈局與執行期診斷工具。
NGINX 1.31.5:Control API 與 Predicate Locations
這個版本新增的 Control API 透過 UNIX domain socket 提供 /1/control/processes 與 /1/control/config 端點,可在不依賴 signal 的情況下,以結構化 JSON 即時回報設定重載結果。這讓自動化部署流程能直接用程式檢查重載是否成功,不必再輪詢日誌或猜測訊號是否生效。
另一項改動是 predicate locations,讓 location 區塊的比對對象不再局限於 URI 路徑字串,而能改用先前求值出的變數。官方給的範例是 location $is_ai_scraper { ... } 這種寫法,依變數是否為真值或非空字串決定要不要進入該區塊,等於把條件判斷直接搬進路由層。
NGINX 1.31.5:提前讀取封包與其他修正
新增的 client_body_early_read 指令,把請求 body 的讀取與解析提前到 location 比對之前執行,讓路由規則可以直接依封包內容分流。搭配同時加入的 json_set 指令,可以在比對 location 前先把 JSON 欄位取出寫進 NGINX 變數,兩者合起來讓 payload-aware 路由不必再借助 Lua 或第三方模組。
- FastCGI 參數超過 128 bytes、uWSGI 參數超過 256 bytes 時的編碼錯誤已修正
- HTTP/2 下緩衝回應處理與 worker 在檔案描述符耗盡時關閉的記憶體安全問題已修正
- QUIC 連線在握手完成後收到的 CRYPTO frame 會被拒絕,並修正 JSON 解析的溢位判斷
C++26 物件常駐:反射與註解重新定義記憶體佈局
在 CppCon 2026 的主題演講預告中,Google 研究員 Laurie Kirk 以《The Address is Not The Place》為題,探討 物件常駐(object residency)——物件在 RAM、CXL 記憶體、遠端記憶體與快閃儲存等不同層級之間該如何被放置。她指出作業系統與編譯器目前多半把記憶體分層做得對開發者透明,結果是分層策略完全看不到程式的存取模式意圖。
Kirk 主張把部分放置決策交還給開發者,讓程式碼能標註物件該被視為熱資料或冷資料,再由支援分層的配置器據此決定實際位置。這個構想奠基於已納入 C++26 的兩項提案:負責靜態反射的 P2996,以及替反射補上標註語法的 P3394——後者引入形似屬性(attribute)但語意不同的 [[=annotation]] 寫法,讓反射程式碼能在編譯期讀出開發者寫在宣告上的標籤,如同 [[likely]]、[[unlikely]] 暗示熱冷路徑,只是延伸到了資料佈局。
Go 1.27 的 Goroutine 洩漏剖析器
Go 官方部落格同步發布文章,介紹 Go 1.27 新增的 goroutine 洩漏剖析器(goroutine leak profile)。所謂 goroutine 洩漏,是指某個 goroutine 卡在阻塞狀態,而解除阻塞所需的條件永遠不會被滿足,長期累積會拖累記憶體用量與 GC 負擔。
剖析器借用一套類似 GC 的可達性分析:先把目前未被阻塞的 goroutine 標記為存活根,接著追蹤這些存活 goroutine 所引用的記憶體,再檢查被阻塞的 goroutine 是否持有其中的 channel 或 sync 原語(Mutex、RWMutex、WaitGroup、Cond)。只要有新的 goroutine 因此被判定存活,就重新納入根集合繼續疊代,直到沒有新的存活 goroutine 出現,最後未被標記者即視為洩漏。官方表示此法幾乎不會產生誤判,但目前僅能抓出經由 channel 與 sync 套件原語造成的洩漏。
剖析結果可透過 runtime/pprof 新增的 goroutineleak 類型取得,或直接呼叫 net/http/pprof 掛出的端點:
curl http://localhost:6060/debug/pprof/goroutineleak > leak.prof
go tool pprof leak.prof文章舉的典型案例,是多個 goroutine 把結果寫進同一個未緩衝 channel,一旦呼叫端提前 return,尚未送出結果的 goroutine 就會永遠卡在 send 呼叫上;修法是把 channel 改成有緩衝區的 make(chan result, len(ws)),讓每個 goroutine 送出結果後就能結束,不必等待接收端。文中另外整理了 CockroachDB、etcd、Kubernetes 與 Moby 過去在正式環境中,因忘記解鎖、timeout 競爭或 channel 與 mutex 混用而造成的真實洩漏案例。
原始來源:NGINX Blog、isocpp.org、Go Blog