当使用Java对象流（ObjectInputStream/ObjectOutputStream）进行网络传输时，若父类未实现Serializable接口，子类虽可序列化，但父类字段（如泛型ID）在反序列化后将被初始化为默认值（如null），造成数据丢失。根本原因是Java序列化机制仅序列化显式声明为Serializable的类及其可访问字段，父类状态不会自动继承。
当使用java对象流（objectinputstream/objectoutputstream）进行网络传输时，若父类未实现serializable接口，子类虽可序列化，但父类字段（如泛型id）在反序列化后将被初始化为默认值（如null），造成数据丢失。根本原因是java序列化机制仅序列化**显式声明为serializable的类及其可访问字段**，父类状态不会自动继承。
在您提供的代码中，User 类正确实现了 Serializable，但其父类 Entity
✅ 正确做法：确保整个继承链可序列化
只需为 Entity 添加 Serializable 接口即可：
public class Entity<ID> implements Serializable { // ← 关键修复：父类必须实现Serializable
private static final long serialVersionUID = 1L; // 建议显式声明，避免版本兼容问题
private ID id;
public ID getId() {
return id;
}
public void setId(ID id) {
this.id = id;
}
}同时保持 User 的实现不变（已正确实现 Serializable）：
public class User extends Entity<Long> implements Serializable {
private static final long serialVersionUID = 2L;
private String name;
private String email;
private List<String> friends;
public User(Long id, String name, String email) {
this.setId(id); // 现在setId操作会被完整保留
this.name = name;
this.email = email;
this.friends = new ArrayList<>();
}
// 建议重写toString便于调试
@Override
public String toString() {
return "User{id=" + getId() + ", name='" + name + "', email='" + email + "'}";
}
}⚠️ 注意事项与最佳实践
- serialVersionUID 不可省略：显式声明可避免因编译器自动生成差异导致 InvalidClassException。建议为每个可序列化类定义唯一且稳定的 serialVersionUID。
-
泛型不影响序列化：Entity
中的 id 是 Long 类型实例，在序列化时按实际运行时类型处理，无需额外配置（前提是 Entity 可序列化）。 - transient 字段会被跳过：若未来需排除某些字段（如敏感信息），可用 transient 修饰，但 id 显然不应被标记。
- 替代方案考虑：对于分布式系统，推荐使用更健壮的序列化协议（如 JSON/Protobuf），它们天然规避了 Java 原生序列化的继承链陷阱和安全风险。
✅ 验证修复效果
服务端发送后，客户端反序列化输出将变为：
立即学习“Java免费学习笔记（深入）”；
User{id=1, name='Name', email='[email protected]'}id 不再为 null，表明继承字段已正确持久化与恢复。
总结：Java 序列化不是“深度反射式”拷贝，而是基于类声明的契约行为。任何参与对象图构建的类（包括所有父类），只要其字段需被序列化，就必须显式实现 Serializable。忽略这一点是生产环境中静默数据丢失的常见根源。
