Java对象序列化在分布式系统中本质是解决跨JVM边界的数据表达问题：对象须转为通用字节流才能存入Redis或经RPC传输，接收方再反序列化还原；需统一协议、注意兼容性与安全字段。
Java对象序列化在分布式缓存（如Redis）和RPC调用（如Dubbo、gRPC）中，本质是解决“跨JVM边界的数据表达”问题——对象不能直接搬过去，必须变成通用字节流，再被另一端准确还原。
Redis缓存中怎么用序列化
Redis本身只存字节或字符串，Java对象要进Redis，必须先转成字节流；读取时再反序列化回对象。
- 原生Java序列化：实现
Serializable接口后，用ObjectOutputStream写入字节数组，再存入Redis。优点是零配置，缺点是体积大、速度慢、无法被其他语言读取 - JSON方式（推荐多数业务场景）：用Jackson或Fastjson把对象转成字符串存Redis。可读性强、跨语言、调试方便；但丢失类型信息，反序列化需指定Class，集合泛型容易出错
- 注意敏感字段：用
transient修饰密码、token等字段，它们不会进入序列化流程 - 建议统一配置序列化器：Spring Data Redis支持自定义
RedisTemplate的valueSerializer，避免每个地方手动编解码
RPC调用中怎么用序列化
RPC本质是远程方法调用，参数和返回值都要跨网络传输，序列化是框架底层自动完成的环节，但选型直接影响性能和稳定性。
- Dubbo默认用Hessian2（兼容Java原生语义，比原生快、体积小），也支持Kryo、FastJson、Protobuf
- gRPC强制使用Protobuf：需提前定义
.proto文件，生成代码，类型安全、高效、跨语言，但灵活性低——不支持任意Java对象，必须按Schema建模 - 自研RPC或轻量框架常选Kryo：性能极佳，适合内部高性能服务，但升级类结构时需谨慎处理兼容性
- 无论哪种方案，都要求服务提供方与消费方使用相同序列化协议，且类定义（尤其是字段名、类型、
serialVersionUID）保持一致，否则反序列化失败
选型关键看三点
不是技术越新越好，而是匹配实际约束：
立即学习“Java免费学习笔记（深入）”；
- 是否跨语言：如果前端Node.js或Go服务也要消费数据，优先选JSON或Protobuf；纯Java生态可考虑Kryo或Hessian
- 性能敏感度：高频调用、大数据量（如实时风控、交易流水）建议压测对比，Protobuf/Kryo通常比JSON快2–5倍，体积小30%–60%
- 运维与排障成本：JSON可直接用redis-cli查看内容，Protobuf需工具解析，原生序列化出错时堆栈难定位
常见踩坑提醒
这些细节不显眼，但上线后容易引发故障：
- 没设
serialVersionUID：类结构微调后反序列化直接抛InvalidClassException - 缓存中混用多种序列化方式：比如部分用JSON、部分用原生，key相同但value格式不一，读取时类型转换异常
- RPC超时重试+非幂等序列化：某些序列化器（如老版本Kryo）在多线程下非线程安全，重试时可能污染状态
- 未过滤循环引用：含父子关系的对象（如User→Order→User）若没配置深度限制，序列化会栈溢出
