Java序列化类库与Serializable详解

Java原生Serializable因反射遍历字段、写入冗余元数据导致慢且体积大，反序列化时自动调用readObject引发远程代码执行风险；serialVersionUID不一致、未实现接口、transient/static字段丢失是常见错误。

Java原生Serializable为什么慢又不安全

Java原生Serializable接口只是个标记接口，序列化逻辑由JVM内置的ObjectOutputStream实现，它依赖反射遍历字段、写入类元数据（包括serialVersionUID、字段名、类型签名等），导致序列化体积大、速度慢；更关键的是，反序列化时会自动调用任意类的readObject方法，攻击者构造恶意字节流可触发任意代码执行——JDK 9+虽默认禁用部分危险类，但未彻底解决根本问题。

常见错误现象：java.io.InvalidClassException: local class incompatible（serialVersionUID不一致）、java.io.NotSerializableException（引用了未实现Serializable的类）、反序列化后static或transient字段值丢失但预期保留。

• 所有非transient非static字段都会被序列化，包括父类中声明的（只要父类也实现了Serializable）
• serialVersionUID必须显式声明为private static final long，否则每次编译生成的值不同，跨版本反序列化必然失败
• 若类有自定义writeObject/readObject，必须调用defaultWriteObject/defaultReadObject，否则非transient字段不会被处理

Jackson和Gson处理Java对象序列化时的坑

Jackson（ObjectMapper）和Gson本质是JSON序列化库，不是Java对象序列化替代品——它们不保存类信息、不支持transient语义、无法还原final字段原始值，且默认忽略static字段。但因JSON格式通用、体积小、可读性强，实际开发中远比原生Serializable常用。

使用场景：HTTP API响应、配置文件存储、日志结构化输出。不适合场景：RPC二进制传输、需要精确还原对象状态（如含ThreadLocal、InputStream等不可序列化资源）。

• Jackson默认不序列化transient字段，但可通过@JsonInclude(Include.NON_NULL)等注解控制，而Gson默认序列化所有字段（包括transient），需显式配置GsonBuilder.excludeFieldsWithModifiers(Modifier.TRANSIENT)
• 两者都要求目标类有无参构造函数，否则反序列化失败（Gson报InstantiationException，Jackson报MismatchedInputException）
• 对泛型集合（如List）反序列化，Jackson需传TypeReference，Gson需传TypeToken，漏掉会导致运行时类型擦除问题

ObjectMapper mapper = new ObjectMapper();
// Jackson反序列化泛型List
List list = mapper.readValue(json, new TypeReference>() {});

Gson gson = new Gson();
// Gson反序列化泛型List
Type type = new TypeToken>() {}.getType();
List list2 = gson.fromJson(json, type);

Kryo和FST这类二进制序列化库的适用边界

Kryo和FST绕过反射、直接操作字节码生成序列化器，性能比原生Serializable高5–10倍，体积小30%–50%，适合内部RPC、缓存（如Redis存储Java对象）、游戏状态快照等对性能敏感的场景。但它们牺牲了兼容性与安全性：类结构变更后旧数据无法反序列化，且默认开启注册机制（Kryo需register()，FST需registerClass()），未注册类直接抛异常。

容易踩的坑：ArrayList、HashMap等JDK集合类需手动注册才能获得最佳性能；Kryo默认不支持final字段（需启用setRegistrationRequired(false)，但会降低安全性）；FST在JDK 17+存在兼容问题，某些版本反序列化record类失败。

• Kryo 5.x默认关闭循环引用支持，需调用kryo.setReferences(true)，否则对象图中有环会栈溢出
• FST的FSTConfiguration.createDefaultConfiguration()已废弃，新项目应改用FSTConfiguration.createJsonConfiguration()避免NPE
• 两者都不处理Serializable接口逻辑，writeObject等钩子方法完全无效

选型时真正该看的三个指标

别只盯着“性能排行榜”，实际落地要盯住三点：是否跨语言、是否需长期存储、是否可控输入源。微服务间用Protobuf（跨语言+向后兼容），内部模块通信用Kryo（性能优先），Web前端交互用Jackson（JSON标准+浏览器友好），日志/临时缓存用原生Serializable（仅限同一JDK版本短时复用）。

最容易被忽略的是版本漂移问题：Kryo/FST序列化结果随类字段增减立即失效，而Protobuf通过optional字段和tag编号容忍新增/删除；Jackson虽能忽略未知字段，但字段类型变更（如int→String）仍会抛异常。

如果还在用Serializable做网络传输，现在就该停。不是因为技术不行，而是没人再为它修漏洞、做优化，连JDK官方文档都明确写着：“It is not suitable for long-term storage or for communication between systems.”