Java 原生序列化的問題

1. 性能差

   • Java 自帶的序列化是基于反射的，序列化時需要寫入大量類元數據（類名、字段描述、版本號等），字節流臃腫。

   • 反序列化時依賴反射和對象創建，速度比 Protobuf/Avro 慢一個數量級。

2. 不跨語言

   • Java 序列化生成的字節流格式只有 JVM 認識，Python、Go、C++ 完全沒法直接解析。

   • 現代分布式系統（Kafka、RocketMQ、Spark、Flink）都追求多語言生態，Java 序列化天然不適合。

3. 可演進性差

   • Java 原生序列化嚴重依賴類的 serialVersionUID。

   • 一旦類結構變化（比如加字段、刪字段），舊數據往往無法反序列化，容易導致兼容性問題。

4. 安全問題

   • 反序列化漏洞（Java 反序列化攻擊）是安全領域的經典問題。

   • 惡意字節流可能觸發遠程代碼執行 (RCE)。這也是很多中間件禁用 Java 原生序列化的原因。

5. 可讀性差

   • 序列化后的字節流是二進制+類信息，幾乎不可讀，不方便調試和排查問題。

JSON/Avro/Protobuf 的優勢

1. 跨語言

   • JSON 是純文本，任何語言都能解析。

   • Avro/Protobuf 有官方/第三方 SDK，Java/Python/Go/C++ 都支持。

2. 高性能 & 小體積

   • Protobuf、Avro 屬于二進制協議，比 JSON 更小更快。

   • 比 Java 原生序列化小很多，網絡傳輸更高效。

3. 良好的 schema 演進性

   • Avro/Protobuf 支持 Schema 演進：可以在不影響舊數據的情況下新增字段、設置默認值。

   • 在數據流里升級服務不會導致舊數據無法解析。

4. 安全

   • 沒有 Java 反序列化漏洞。

   • 數據是純結構化存儲，不會觸發任意代碼執行。

5. 可讀性

   • JSON 是純文本，方便調試。

   • Avro/Protobuf 可以借助 Schema 工具解析，查看字段名和值。

舉個對比表

實際使用場景

• 日志/配置/輕量數據 → JSON（方便人類可讀）

• 大規模流式處理（Kafka/RocketMQ/Spark/Flink） → Avro 或 Protobuf（小 + 快 + 可演進）

• 跨語言 RPC（gRPC、Thrift） → Protobuf、Thrift

?? 所以總結：
生產環境不用 Java 原生序列化，是因為它慢、不兼容、不安全、擴展性差。
而 JSON/Avro/Protobuf 則能保證 跨語言、性能、兼容性、安全性，這就是主流選擇。

 轉發請注明出處：http://www.rzrgm.cn/fnlingnzb-learner/p/19073709