什么是序列化与反序列化
你在平时的开发中肯定发现实体类会实现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异常。
当我们在最开始时指定
@Datapublic 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的值也不会被影响(不会被序列化)。”
大家可以思考,如果需要序列化被这两种关键字修饰的属性,该怎么做呢?