为什么实现了Serializable接口还要指定serialVersionUID值呢？

什么是序列化与反序列化

你在平时的开发中肯定发现实体类会实现Serializable接口，并且指定serialVersionUID的值。像这样

你可能会有疑问，为什么要实现Serializable接口呢。实现这个接口是为了序列化和反序列化。

如果这个实体类有内存和硬盘的数据交互，或者内存与网络的数据交互时，就需要序列化和反序列化了。这时不实现Serializable接口就会出现java.io.NotSerializableException异常。

那么什么是序列化和反序列化呢？

“序列化：将对象转换成字节序列的过程 反序列化：将字节序列恢复成对象的过程 ”

所以如果你编写的实体类不需要与硬盘交互。比如这个对象装载的数据不用存储在数据库，或者不需要网络传递（比如发送到Kafka，Redis等）。就不用实现Serializable。

不知你发现了没，我们平时数据传输用的JSON格式实际就是将对象转换成字符串了。我们来看看String的源码

String不仅实现了Serializable接口还指定了serialVersionUID的值。

你可能会有疑问，已经实现Serializable了，为什么一定要指定serialVersionUID的值呢？

为什么还要指定serialVersionUID

定义实体类

我们来举个例子，先写一个实体类：

这里我们不指定serialVersionUID值，来看看会有什么影响。

编写方法

1.将实体封装数据的实体写到文件中（内存 -> 硬盘），这里就是序列化。

2.将文件中的数据转成实体（硬盘 -> 内存），这里是反序列化。

测试

测试结果

序列化前：UserInfo(name=Lvshen, hobby=看书)
反序列化后：UserInfo(name=Lvshen, hobby=看书)

数据成功从内存写进文件，并且成功从文件读取出来。

修改实体

这时我们在UserInfo里面添加一个新字段address。

直接反序列化

然后注释掉序列化的方法，我们再从文件读取数据

测试结果如下：

发现序列化的serialVersionUID值和反序列化的serialVersionUID不一致。导致InvalidClassException异常。

当我们在最开始时指定

@Data
public class UserInfo implements Serializable {
    private static final long serialVersionUID = 1L;

    private String name;  //姓名
    private String hobby; //爱好
   
}

然后再走一遍上面的流程【序列化 -> 反序列化 -> 修改实体 -> 反序列化】。

序列化前：UserInfo(name=Lvshen, hobby=看书, address=null)
反序列化后：UserInfo(name=Lvshen, hobby=看书, address=null)

发现就算新增了address字段，还是能正常反序列化。

当对同一个实体序列化反序列化时，需要serialVersionUID值一致才能成功。如果我们不显示指定serialVersionUID，在序列化时会自动生成一个serialVersionUID。当实体类改动了，反序列化时，会生成一个新serialVersionUID。这两个serialVersionUID的值肯定不一致，从而反序列化会失败。但是如果显示指定，就不会生成新serialVersionUID值了。反序列化的serialVersionUID就是原序列化的serialVersionUID。

实际开发中实体类肯定会不断迭代修改的，所以指定一个显示的serialVersionUID值，就不用担心序列化和反序列化的问题了。

下列情况可以不需要serialVersionUID：

• 如果你的实体类新增的属性被static修饰的，这个属性就不会被序列化。
• 或者实体类有个属性被transient修饰，修改transient的值也不会被影响（不会被序列化）。

大家可以思考，如果需要序列化被这两种关键字修饰的属性，该怎么做呢？