Java原生序列化在分布式系统中已不适用，因其体积膨胀严重、性能极低、版本兼容性脆弱且存在明确安全风险；Kryo适用于JVM内高性能场景，Protobuf则为跨语言与长期演进的工业标准。
Java 原生序列化（java.io.Serializable）在分布式系统中已明显不适用，核心问题不是“能不能用”，而是“用了会拖垮性能、埋下隐患”。它在微服务调用、缓存共享、消息传输等场景下，会直接拉高延迟、放大网络开销、加剧 GC 压力，甚至引入反序列化漏洞风险。
原生序列化在分布式中的四大硬伤
• 体积膨胀严重：每个对象都附带完整类名、字段名、继承链、serialVersionUID 等元数据。一个仅含 2 个字符串字段的 User 对象，原生序列化后字节数通常是 Kryo 的 3–5 倍，Protobuf 的 6 倍以上。
• 性能极低：依赖运行时反射遍历字段，频繁创建临时对象（如 ObjectOutputStream 内部缓冲），序列化速度普遍仅约 50 MB/s，比 Protobuf（350 MB/s）和 Kryo（400 MB/s）慢一个数量级。
• 版本兼容性脆弱：字段增删、类型变更、父类修改都可能触发 InvalidClassException；没有显式 schema 约束，升级需全链路强同步，运维成本极高。
立即学习“Java免费学习笔记（深入）”；
• 安全风险明确：JDK 9+ 已默认禁用反序列化黑名单外的类，但漏洞利用链（如 Apache Commons Collections）仍广泛存在，生产环境禁用原生反序列化已是行业共识。
Kryo：JVM 内高性能首选（单语言高吞吐场景）
Kryo 专为 Java 生态优化，适合服务内部通信、Redis 缓存对象、Spark shuffle 等同构环境。
• 必须显式注册类：调用 kryo.register(User.class)，避免运行时全类名查找与反射，降低 GC 压力。
• 线程不安全，需隔离使用：每个线程应持有独立 Kryo 实例，推荐用 ThreadLocal<kryo></kryo> 管理。
• 开启严格注册模式：设 kryo.setRegistrationRequired(true)，防止未注册类触发动态注册导致并发异常或内存泄漏。
• 慎用 Unsafe 模式：虽可提速，但要求类 public、有无参构造、字段非 final，且绕过 JVM 安全检查，边缘场景才启用。
Protobuf：跨语言与长期演进的工业标准
适用于微服务间通信（尤其混合语言栈）、gRPC 接口、配置下发、日志采集等需契约约束与向后兼容的场景。
• 先写 .proto 文件，再生成代码：定义字段编号、类型、是否可选（optional/repeated），所有结构编译期固化，零运行时反射。
• 禁止动态解析高频路径：不用 DynamicMessage 或 Any 做主数据载体，它们会带回类似原生序列化的性能与安全问题。
• 配合框架深度集成：在 gRPC 中天然支持；在 Netty 中搭配 ProtobufVarint32FrameDecoder 处理变长帧；Dubbo 需统一配置 serialization="protobuf" 并确保双方使用同一版生成类。
• 体积与兼容性双赢：二进制紧凑（比原生小 60%+），字段可增可删、类型可宽松演进，老服务无需重启即可兼容新字段。
选型关键看三点
• 是否跨语言：是 → Protobuf 或 Avro；否 → Kryo 更轻快。
• 是否需要长期兼容与强契约：是 → Protobuf（schema 即文档）；否 → Kryo 更灵活。
• 是否已在用 gRPC / Kafka Schema Registry / Hadoop Avro：已有生态 → 优先对齐，避免协议碎片化。
