Kryo和Protostuff可显著提升I/O性能：Kryo吞吐量为JDK原生5–10倍、体积小30%–50%，适合纯Java高吞吐场景；Protostuff免.proto文件、零反射、兼容JDK类型，适合轻量跨语言通信。
直接用 Kryo 或 Protostuff 替代 Java 原生序列化，能显著提升 I/O 速度——实测中，Kryo 序列化吞吐量通常是 JDK 的 5–10 倍，体积小 30%–50%；Protostuff 接近 Protobuf 性能，无需 .proto 文件，兼容 JDK 类型且零反射。关键不是“换库”，而是避开原生序列化的三大硬伤：冗余元数据、强耦合类结构、无注册机制导致的反射开销。
优先选 Kryo（纯 Java 高吞吐场景）
Kryo 在 JVM 内部性能最优，适合 Redis 缓存、Spark RDD、消息队列 payload 等单语言高频序列化场景。
-
必须提前注册核心类：调用
kryo.register(User.class)，避免运行时反射查找类信息；基础类型（String、List、Map 等）已预注册，但自定义类务必显式注册 -
禁用动态注册：设置
kryo.setRegistrationRequired(true)，防止未注册类触发反射 + GC，引发并发不稳定 -
线程安全封装：Kryo 实例非线程安全，推荐用
ThreadLocal<Kryo>每线程独享，避免同步锁开销 - 慎用 Unsafe 模式：开启后可再提速 15%–20%，但要求类 public、有无参构造、字段非 final；生产环境建议关闭，除非压测确认稳定
选 Protostuff（免 .proto 的轻量跨语言兼容）
Protostuff 不依赖 IDL 文件，直接基于 POJO 生成二进制 schema，比 Protobuf 更易接入，又比 JDK 原生更紧凑、更快，适合微服务间通信或需长期存储的业务对象。
-
使用 RuntimeSchema 获得零配置优势：无需代码生成，
Schema<User> schema = RuntimeSchema.getSchema(User.class)即可获取运行时 schema -
复用 Output/Input 对象：避免每次序列化都 new
LinkedBuffer或byte[]，用池化或 ThreadLocal 管理缓冲区 -
避免泛型擦除问题：对
List<String>这类类型，需配合RuntimeSchema的泛型支持扩展（如引入kryo-serializers），否则反序列化可能丢失类型信息 - 不依赖 serialVersionUID：字段增删默认兼容（新增字段为 null，缺失字段跳过），比 JDK 原生健壮得多
替换 JDK 序列化的具体步骤
不是简单改一行代码，而是系统性迁移：
立即学习“Java免费学习笔记（深入）”；
-
定位原生序列化点：搜索
ObjectOutputStream、ObjectInputStream、实现Serializable但没设serialVersionUID的类 -
统一序列化入口：封装成工具类（如
Serializer<T>接口），内部切换 Kryo/Protostuff 实现，业务层无感知 - 校验兼容性边界：测试字段增删、类型变更（如 int → Integer）、继承关系调整后的反序列化行为，Protostuff 默认比 JDK 更宽容
- 监控体积与耗时变化：对比序列化后 byte[] 长度、十万次序列化耗时（JMH 测试），确认提升是否达预期（通常体积降 40%+，时间降 70%+）
注意事项与避坑点
高效不等于无代价，几个容易忽略的细节决定成败：
-
不要在类里混用多种序列化逻辑：比如某字段用
transient排除 JDK 序列化，却期望 Kryo 自动序列化它——Kryo 默认全字段序列化，需手动配置FieldSerializer控制 - Redis 存储时注意字节数组边界：Kryo 输出是 raw bytes，直接 set 到 Redis 没问题；但若中间转 String（如 Base64），会膨胀约 33%，反而拖慢
- 升级时保留旧格式读取能力：上线初期可双写（JDK + Kryo），或加版本 header 字节，逐步灰度切换，避免存量数据不可读
- Protostuff 的默认浮点精度：float/double 序列化使用 IEEE 754 标准，与 JDK 一致；但若业务对精度敏感（如金融计算），需确认反序列化后值未因位宽差异偏移
