开篇语

哈喽，各位小伙伴们，你们好呀，我是喵手。运营社区：C站/掘金/腾讯云/阿里云/华为云/51CTO；欢迎大家常来逛逛

  今天我要给大家分享一些自己日常学习到的一些知识点，并以文字的形式跟大家一起交流，互相学习，一个人虽可以走的更快，但一群人可以走的更远。

  我是一名后端开发爱好者，工作日常接触到最多的就是Java语言啦，所以我都尽量抽业余时间把自己所学到所会的，通过文章的形式进行输出，希望以这种方式帮助到更多的初学者或者想入门的小伙伴们，同时也能对自己的技术进行沉淀，加以复盘，查缺补漏。

小伙伴们在批阅的过程中，如果觉得文章不错，欢迎点赞、收藏、关注哦。三连即是对作者我写作道路上最好的鼓励与支持！

1. 为什么要避免（或谨慎使用）Java 原生序列化？

主要缺点：

• 性能与体积差：Java 序列化会写入类元信息、字段名/类型等，二进制通常比 protobuf/avro/kryo 大很多、速度也慢（尤其是对象图复杂时）。
• 安全风险极高：反序列化未受信任的数据会导致 RCE（常见的 gadget 链攻击，见 ysoserial），历史上大量漏洞来自 Java 序列化。
• 兼容性差、脆弱：类结构微小改动（字段名/类型/serialVersionUID）可能导致失败或隐蔽错误。
• 对象图膨胀/内存问题：复杂的对象图会导致大量临时对象、GC 压力和内存膨胀。
• 语言/平台互操作性差：只适合 Java，跨语言消息很困难。

结论：对内部、完全受信任、短生命周期的缓存可能还可用，但对于消息队列、跨服务通信、跨语言接口或从外部读取数据坚决建议使用更安全/高效/可管控的方案（Protobuf、Avro、Kryo（受限）等）。

2. 二进制协议与 schema 管理（为什么要有 schema？）

二进制协议（Protobuf/Avro/Thrift/FlatBuffers）提供：

• 小体积、快解析（相比文本或 Java 序列化）
• 强类型、明确字段编号：便于演进（向前/向后兼容）
• 跨语言支持：生成多语言代码（Java、Go、Python、C++…）
• 可选的 schema registry（模式仓库）管理版本与兼容性（常见于 Kafka/Confluent + Avro/Protobuf）

Schema 管理要点：

• 使用明确的字段编号（Protobuf 的 field numbers）并保留已删除字段号（或用 reserved）。
• 维护语义向后/向前兼容策略（哪些改动是安全的，哪些不是）。
• 将 schema 存入注册中心（Schema Registry），在消费者端校验/演进策略（BACKWARD/ FORWARD/ FULL 等）。
• 对于 Avro：schema 与数据可以解耦（writer/reader schema），便于演进。Protobuf 则依赖于预先约定的 field numbers 与兼容写法（避免改变已有 field number 与语义）。

3. 兼容性策略（版本化、向前向后兼容）

常见安全演进原则（以 Protobuf 为例）

• 可做的改动（向后/向前安全）：添加字段（使用新的 field number），将字段设为 optional（proto3 默认有默认值），增加枚举的新成员（注意默认值问题）。

• 不安全的改动：改变已有字段的编号、更改 field 的语义/类型（int ↔ string）、删除字段号后再复用该编号（除非使用 reserved 并有完全掌控）。

• 兼容策略：

  • Forward compatibility（向前兼容）：新写入的数据可被旧读者读取（新字段会被忽略或默认），适合先生产后消费场景。
  • Backward compatibility（向后兼容）：旧写入的数据可被新读者读取（新读者能处理旧数据）。
  • 选择合适策略并在 schema registry 强制检测（例如禁止破坏性变更）。

4. 在缓存 / 消息队列 / 网络中的应用注意点

• 缓存（如 Redis / Memcached）：

  • 优先用紧凑二进制（Protobuf/Kryo/Smile）以减少网络与内存占用。
  • 考虑对象版本（缓存中的旧数据结构），使用 version 字段或版本解码逻辑。

• 消息队列（Kafka）：

  • 使用 schema registry（Confluent / Apicurio）管理 schema，producer 写入时附加 schema id；consumer 能解出数据并做兼容校验。
  • 把 schema 演进策略放到 CI/CD 流程中，避免生产中突然破坏兼容性。

• RPC / 网络（gRPC / HTTP）：

  • gRPC + Protobuf 是跨语言高性能选择。
  • 对外接口要考虑版本路径（v1/v2）或兼容层（adapter）。

• 安全：对所有外部输入都当作不可信，使用签名/加密和严格的 schema 校验。

5. 实战练习：用 Protobuf 序列化并比较大小/速度

下面给出一个完整的示例流程：.proto 文件 → 生成 Java 类 → 用三种方式序列化（Java 原生、Protobuf、Kryo）并比较 序列化字节大小 与 序列化/反序列化吞吐。我还提供 JMH 示例用于严谨测量。

5.1 proto 文件（person.proto）

syntax = "proto3";
package demo;

message Address {
  string street = 1;
  string city   = 2;
  string zip    = 3;
}

message Person {
  string name     = 1;
  int32 id        = 2;
  repeated string emails = 3;
  Address address = 4;
  bool active     = 5;
}

使用 protoc 或 Maven/Gradle 插件生成 Java 类（protoc --java_out=... person.proto 或 protobuf-maven-plugin）。

5.2 Java POJO（用于 Java 原生与 Kryo 示例）

public class Address implements Serializable {
    private String street;
    private String city;
    private String zip;
    // constructors, getters, setters
}

public class PersonPOJO implements Serializable {
    private String name;
    private int id;
    private List<String> emails;
    private Address address;
    private boolean active;
    // constructors, getters, setters
}

5.3 Protobuf 序列化示例（使用生成的类）

// build Person proto
demo.Person proto = demo.Person.newBuilder()
    .setName("Alice")
    .setId(1001)
    .addEmails("alice@example.com")
    .setAddress(demo.Address.newBuilder().setStreet("1 Main").setCity("City").setZip("000"))
    .setActive(true)
    .build();

// serialize
byte[] data = proto.toByteArray();

// deserialize
demo.Person p2 = demo.Person.parseFrom(data);

5.4 Java 原生序列化示例

ByteArrayOutputStream baos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(baos);
oos.writeObject(personPojo);
oos.close();
byte[] bytes = baos.toByteArray();

// deserialize
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bytes));
PersonPOJO p = (PersonPOJO) ois.readObject();

5.5 Kryo 示例

Kryo kryo = new Kryo();
kryo.register(PersonPOJO.class);
kryo.register(Address.class);

ByteArrayOutputStream baos = new ByteArrayOutputStream();
Output output = new Output(baos);
kryo.writeObject(output, personPojo);
output.close();
byte[] bytes = baos.toByteArray();

Input input = new Input(new ByteArrayInputStream(bytes));
PersonPOJO p2 = kryo.readObject(input, PersonPOJO.class);

5.6 测量（两种方式）

快速粗略测量（不严谨）

int N = 100_000;
long t0 = System.nanoTime();
for (int i=0;i<N;i++){
  byte[] b = proto.toByteArray();
}
long t1 = System.nanoTime();
System.out.println("proto serialize avg ns: " + ((t1-t0)/N));

优点：快速、简单；缺点：JIT、GC、分配影响显著，不够精确。

严谨测量（推荐） — 用 JMH

写一个 @Benchmark 类，分别 benchmark protobuf/java-serialization/kryo 的 serialize 和 deserialize。用 @State(Scope.Benchmark) 预构建对象和缓冲，配置 warmup/iteration，得到更可信的吞吐或平均时间。JMH 是微基准的行业标准。

pom 依赖示例（片段）：

<dependency>
  <groupId>org.openjdk.jmh</groupId>
  <artifactId>jmh-core</artifactId>
  <version>1.36</version>
</dependency>
<dependency>
  <groupId>com.esotericsoftware</groupId>
  <artifactId>kryo</artifactId>
  <version>5.5.0</version>
</dependency>
<dependency>
  <groupId>com.google.protobuf</groupId>
  <artifactId>protobuf-java</artifactId>
  <version>3.21.12</version>
</dependency>

5.7 典型观测（经验值，视对象复杂度而异）

• Protobuf / Kryo：通常序列化后体积小、解析快（低几十到几百字节，低延迟）。
• Java 原生序列化：通常比 Protobuf 大很多，反序列化/序列化慢（尤其在深对象图上）。
• JSON（Jackson）：可读性强，但体积与 CPU 开销通常最大（文本化成本）。

注意：具体数字依赖对象复杂度、JVM、JIT 与测量方法，上述仅为常见趋势。用 JMH 在你的目标环境中测量才是可靠依据。

6. 常见陷阱与安全实践（必须认真对待）

常见陷阱：

• 误用 Java 序列化读取来自不受信任的来源 → RCE。
• 滥用 serialVersionUID 以“绕过”版本错误（会隐藏潜在不兼容问题）。
• 随意复用已删除 field number（会影响老客户端）。
• 忽视对象图与内存分配成本（大量短生命周期对象导致 GC 压力）。
• Kryo 默认行为可能允许构造任意类（在接收端必须限制 class 注册/白名单）。

安全最佳实践：

1. 不反序列化不受信任的数据；如果必须，使用严格的白名单/过滤器（Java 9+ 的 ObjectInputFilter / JEP 290）。
2. 对外公开 API 使用语言中立的 schema（二进制或 JSON），并签名/加密消息。
3. 使用 schema registry 并在 CI 中做兼容性检查。
4. 对 Kryo 等“快而不安全”的库只在受控内网、受信任的部署下使用，并对 class 注册/反序列化做白名单。
5. 对敏感场景使用 JWT/signed payloads 或 TLS，防止中间人篡改/注入。
6. 定期扫描依赖与已知 gadget 库（例如使用安全扫描器）。

7. 迁移 / 选型检查清单（把系统从 Java 序列化迁移到 Protobuf/Avro 的步骤）

1. 梳理数据模型：把需要序列化的 POJO 映射到 schema（.proto / .avsc）文件。
2. 确定兼容策略：选择 FORWARD / BACKWARD / FULL，并制定字段变动规则。
3. 引入 schema registry（可选但推荐）：统一管理版本与校验。
4. 实现序列化/反序列化层（Adapter）：把生产/消费代码改为调用生成的 protobuf 类或 adapter。
5. 灰度迁移：在一段时间内同时支持旧格式与新格式（consumer 能处理两种），或加入回退逻辑。
6. 基准测试：用 JMH 在生产样本数据上测试性能与体积，确认优势。
7. 监控/回滚策略：监控消费失败率、序列化异常，并准备回滚方案。
8. 安全审计：确保反序列化路径安全（白名单/签名/审计）。

8. 参考实现资源与工具（实用推荐）

• Protobuf：protoc, protobuf-java, protobuf-maven-plugin / protobuf-gradle-plugin
• Avro：avro-tools, avro-maven-plugin，适用于 schema-evolution 强场景（与 Kafka schema registry 常配）
• Kryo：性能好但安全需控制；常用于内存缓存序列化（例如 Hazelcast/Redis 客户端自定义序列化）
• JMH：微基准测试工具（用来比较吞吐/延迟）
• Jackson (JSON / Smile / CBOR)：如果需要可读日志或部分二进制格式（Smile/CBOR）

9. 快速示例：我可以为你做的几件事（选一项回复即可）

1. 生成一个可下载的 Maven 项目，内含：.proto，生成脚本，示例代码（Java 原生 / Protobuf / Kryo / Jackson），并带有 JMH 基准。📦
2. 只要 Protobuf 示例 + JMH benchmark 类（把核心文件贴在聊天里）。🧪
3. 给你一个迁移计划文档（针对具体系统），包含风险点、回滚路径与 CI 校验脚本示例（YAML）。📋
4. 只要安全实践与 ObjectInputFilter 示例代码（如何防止反序列化 RCE）。🔒

请选择一个选项编号或直接回复“都要”。如果你要第 1 项，请告诉我：

• 喜欢 Maven 还是 Gradle？
• 要不要把 JMH 输出的默认参数调整成你生产机器的核数（我可以用通用设置：warmup 3, iterations 5）？

10. 小结（一句话）

不要把 Java 原生序列化当作跨服务或对外通信的默认方案：如果需要高性能、跨语言、可控的演进与安全，请首选 Protobuf/Avro/Kryo（受控）并在生产前用 JMH 做基准测试与用 Schema Registry 做版本管理。😎

… …

文末

好啦，以上就是我这期的全部内容，如果有任何疑问，欢迎下方留言哦，咱们下期见。

… …

学习不分先后，知识不分多少；事无巨细，当以虚心求教；三人行，必有我师焉！！！

wished for you successed ！！！

⭐️若喜欢我，就请关注我叭。

⭐️若对您有用，就请点赞叭。
⭐️若有疑问，就请评论留言告诉我叭。

版权声明：本文由作者原创，转载请注明出处，谢谢支持！