Java 實測多種壓縮演算法效能：GZIP、Deflate、LZ4、Snappy 深度基準測試

前言

資料壓縮在高吞吐系統中無處不在：RPC 回應體、日誌落盤、快取序列化、跨機房同步。選錯演算法可能導致 CPU 瓶頸或頻寬浪費。本文基於 JMH 基準測試，對比 JDK 內建與主流第三方庫在 338 MB 真實文本資料上的壓縮速度、體積、吞吐量，提供選型決策依據。

一、測試對象與環境

• 硬體: Xeon E5-2650 @ 2.00GHz
• 資料: 合併 JDK Javadoc 目錄，338 MB (354,509,602 bytes)
• 框架: JMH, @BenchmarkMode(SingleShotTime), Warmup 2, Measurement 3
• 輸出: ByteArrayOutputStream (避免磁碟 I/O 干擾)

二、壓縮後體積對比

三、壓縮耗時與吞吐量 (核心指標)

四、關鍵結論與選型指南

✅ 即時/線上壓縮 (RPC、HTTP 回應、快取寫入)

• 首選：LZ4 Fast (JNI) — 320 MB/s 幾乎無感知，CPU 佔用極低。
• 純 JDK 替代：Deflate Level 1 — 75 MB/s，無第三方依賴。
• 平衡派：Snappy — 150 MB/s，壓縮率優於 LZ4 Fast。

✅ 離線/批次壓縮 (日誌歸檔、資料湖入湖、備份)

• GZIP / Deflate Level 6-9 — 體積最小，適合長期儲存。
• LZ4 High — 壓縮率接近 Deflate L1，但速度快 5-10 倍。

⚠️ 硬體瓶頸提醒

• HDD 寫入上限 ~100-150 MB/s → LZ4 Fast 已飽和磁碟，再快無意義。
• SSD/NVMe 可跑滿 LZ4 Fast，若網路 10Gbps (1.25 GB/s) 則壓縮不再是瓶頸。
• CPU 核心數限制並行壓縮吞吐，JMH 單執行緒測試為基準，實際可水平擴展。

五、程式碼倉庫

完整 JMH 基準測試原始碼、Maven 依賴設定、各實作 Factory 類請見：
https://github.com/your-repo/java-compression-benchmark

六、總結

「沒有最好的壓縮演算法，只有最適合場景的。」
— 依據 延遲敏感度、CPU 預算、儲存介質、網路頻寬 四維度決策。