Java 中 Protocol Buffers 與 JSON 序列化效能與體積深度比較

前言

在微服務架構與高效能系統中，資料序列化格式的選擇直接影響網路傳輸頻寬與解析速度。本文實測比較 Protocol Buffers (Protobuf) 與 JSON (Gson) 在不同資料量下的序列化體積、壓縮耗時與吞吐量，並附上完整基準測試代碼，幫助開發者依據場景做最佳選型。

一、測試環境與資料準備

• CPU: Intel Xeon E5-2650
• 資料來源: 整合 JDK Javadoc 目錄所有檔案，生成單一 338 MB (354,509,602 bytes) 測試檔
• 測試框架: JMH (Java Microbenchmark Harness)，採用檔案系統快取模擬實際熱資料場景
• 序列化庫: Protobuf (protoc 3.x Java 生成碼)、Gson 2.8.x

二、序列化體積對比

結論：Protobuf 二進制編碼天生體積遠小於 JSON 文字格式；若再搭配 LZ4/Deflate 壓縮，體積優勢更明顯。

三、壓縮/序列化耗時與吞吐量

關鍵發現：

• LZ4 (Fast, JNI) 以 320 MB/s 吞吐量碾壓其他演算法，適合「即時壓縮」場景（如 RPC 回應、日誌落盤）。
• Snappy 平衡速度與壓縮率，適合通用緩存壓縮。
• Deflate Level 1-4 在無第三方庫限制時，為 JDK 內建最佳折衷方案。
• 高壓縮等級 (LZ4 High, Deflate 8-9) 耗時指數級上升，僅適合離線/批次處理。

四、Protobuf vs JSON 實戰代碼片段

4.1 Protobuf 寫入與讀取

// 寫入
Teacher.Builder tea = Teacher.newBuilder().setId(1).setName("testTea");
for (int i=0; i<SIZE; i++) {
    tea.addStudentList(Student.newBuilder().setId(11).setName("shun").setAge(25).build());
}
tea.build().writeTo(new FileOutputStream("proto-" + SIZE));

// 讀取
Teacher t = Teacher.parseFrom(new FileInputStream("proto-" + SIZE));

4.2 JSON (Gson) 寫入

Teacher teacher = new Teacher();
teacher.setStuList(stuList); // List<Student>
new Gson().toJson(teacher); // 輸出字串再寫檔

五、選型建議

1. 極致速度、CPU 受限 → LZ4 (Fast, JNI) 或 Deflate Level 1 (純 JDK)。
2. 需平衡體積與速度、允許第三方庫 → Snappy 或 LZ4 (Fast)。
3. 長期儲存、體積優先 → GZIP / Deflate Level 6-9 或 Protobuf + LZ4 High。
4. 跨語言、強結構驗證 → Protobuf (配合 .proto 定義)。
5. Web API、除錯友善 → JSON (Gson/Jackson)，接受較大體積。

六、原始碼下載

完整 JMH 基準測試代碼、.proto 定義、Maven 專案結構請參考文末附件或專案倉庫。