Zig 0.16 的 std.Io 介面：可交換的非同步 I/O 執行時
lalinsky.com · 2026-05-11
Zig 0.16 引入了 std.Io，一個跨平台的 I/O 與並發抽象介面，讓函式庫程式碼與特定執行時解耦。標準函式庫附帶的 std.Io.Threaded 以作業系統執行緒池實作，而社群函式庫 zio 則提供了基於 stackful coroutine 的高效實作，後端分別對應 Linux 的 io_uring/epoll、BSD/macOS 的 kqueue、Windows 的 IOCP。
背景
Zig 對非同步 I/O 的支援在多個版本中幾度重構。0.16 以 std.Io 介面重新定義邊界：上層程式碼只依賴介面，實作可在編譯期或執行期注入，不綁定任何特定 event loop 語義。這解決了過去 Zig async/await 語法實驗中「編譯器特性與執行時模型耦合過緊」的問題。
核心改動
std.Io.Threaded 使用 OS 執行緒池：建立 10,000 個 task 需約 20 秒，並在系統執行緒上限（約 50,000）附近崩潰。zio 0.11 實作同一介面，相同的 10,000 task 範例只需 10 秒且可擴展至 50,000+ 個並發 task，差距來自 coroutine 相較於 OS thread 的切換成本。
// 對所有 std.Io 實作通用的 task 建立語法
const io = try std.Io.Threaded.init(.{});
try io.spawnTask(handleConnection, .{conn});影響範圍
開發者現在可以寫一次非同步程式碼，透過替換 std.Io 實作來切換執行策略——從執行緒池換成 io_uring coroutine 不需修改業務邏輯。這對建構高並發網路伺服器特別重要：zio 的 io_uring 後端在 Linux 5.1+ 可以利用核心提交佇列批次提交 I/O 操作，進一步減少 syscall 次數。標準函式庫的 std.net.Server API 已圍繞 std.Io 設計，zio 可直接插入。
原始來源：lalinsky.com
Bazel 遠端快取導入 Content-Defined Chunking：兩週省下 300 TiB 上傳
BuildBuddy Blog · 2026-05-16
BuildBuddy 在 Bazel 的遠端快取（Remote Cache）中實作了 Content-Defined Chunking（CDC），在生產環境中達成 40% 上傳量縮減、85% 重複資料消除率，兩週內節省 300 TiB 的重複上傳。CDC 技術本身並不新穎，但將其整合進 Bazel 的 CAS（Content Addressable Storage）協議需要在 Remote APIs 規格層做出修訂。
核心改動
傳統 Bazel 快取以整個 blob 為單位計算 digest，即使連結二進制檔只改了一個函式，整個數百 MB 的 blob 也必須重傳。CDC 依據內容決定分割邊界：以 rolling hash 掃描 blob，當 hash 命中稀少的 pattern 時切割。相同內容無論出現在哪個 blob 都產生相同的 chunk digest，因此已存在快取的 chunk 可直接跳過上傳。
# Remote API 新增兩個操作
SplitBlob # 讀取端：伺服器拆分並返回 chunks
SplicBlob # 寫入端：客戶端上傳 chunks，伺服器重組實作細節
BuildBuddy 的實作包含三個元件：Remote APIs 協議擴展（SplitBlob/SplicBlob）、Bazel combined cache 的 CDC 協調層、以及 executor 端的上傳/下載邏輯。chunk 本身以普通 CAS entry 儲存，key 為 chunk digest，無需特殊儲存格式。伺服器可設定 threshold，小於閾值的 blob 不切割，避免 chunk metadata 開銷超過節省量。
效果
在 BuildBuddy 自身的 repository 上，寫入快取的資料量減少 40%，磁碟快取體積縮小 40%。兩週內合格快取寫入的 chunk 去重率達 85%。效果在大型、位元組穩定的輸出（連結二進制、打包 archive）最顯著，因為這類輸出通常只有尾部隨組建版本變動。
原始來源：BuildBuddy Blog