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等不可序列化资源)。
立即学习“Java免费学习笔记(深入)”;
- 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 Listlist = 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()),未注册类直接抛异常。
Android开发技巧合集pdf版,内容包括:ANDROID常用类库说明,ANDROID文件系统与应用程序架构,ANDROID应用程序结构,ANDROID UI LAYOUT(布局),ANDROID UI 控件,ANDROID UI 美化,ANDROID UI 动画,异步调用,数据存储与读取等。
容易踩的坑: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.”








