当前位置:首页 > 服务端 > 关于Serializable的serialVersionUID

关于Serializable的serialVersionUID

  在实现了Serializable接口的class中,需要声明一个long serialVersionUID,用来标明当前class的版本号,但很多人在编程时,总是不原意去声明这个serialVersionUID,又JVM自己来生成。下面来看看serialVersionUID的作用:

1、如果在序列化写 时的版本号和序列化读 时的版本号,不一致,将会有异常:java.io.InvalidClassException:local class incompatible: stream classdesc serialVersionUID = …, local class serialVersionUID = …

2、那如果在class中不声明这个属性呢?那结果可以就会变得比较诡异了: 

1)、在序列化写 的时候,虚拟机A会为它计算出一个serialVersionUID,计算的方法是依据class的信息,再具体我也不清楚了。

2)、在序列化读 的时候,虚拟机B也会为class计算出一个serialVersionUID,然后做比较。

3)、那么如果两个虚拟机是不同类型的虚拟机,那么计算方法可能就不一样了,于是即使相同的classserialVersionUID也可能会不同,不同的class的,理论上来说,也存在serialVersionUID相同的可能性,所以,serialVersionUID尽量由我们自己来指定,而不要由虚拟机来计算。

3、那如果serialVersionUID一致,而class发生了变化呢? 

1)、如果虚拟机A中的AClass有一个属性,而虚拟机B中的AClass,没有这个属性,那么这个属性将被忽略,而不会有异常。

2)、如果虚拟机A中的AClass没有的属性,而在虚拟机B中多出来的属性,那么这个属性将被赋予一个缺省值,而不会有异常。

3)、如果虚拟机A中的AClass有一个属性,在虚拟机B中的AClass也有这个属性,但这个属性的类型变了,比如说int变成了long,抑或其他的变化,将会有异常:java.io.InvalidClassException:incompatible types for field …

经过序列化而产生的异常都是 java.io.InvalidClassException,不会产生java.lang.ClassCastException,两者还是有比较大的区别的,从名字上就可以看得出来。

看完你还会让JVM自己来生成serialVersionUID吗?你还加@SuppressWarnings("serial")吗?在一个单机上或许看不出什么问题,但在分布式计算、或者你需要提供jar供别人使用的时候,这个问题就会暴露。

作者:海米傻傻
来源链接:https://www.cnblogs.com/haimishasha/p/5058085.html

版权声明:
1、Java侠(https://www.javaxia.com)以学习交流为目的,由作者投稿、网友推荐和小编整理收藏优秀的IT技术及相关内容,包括但不限于文字、图片、音频、视频、软件、程序等,其均来自互联网,本站不享有版权,版权归原作者所有。

2、本站提供的内容仅用于个人学习、研究或欣赏,以及其他非商业性或非盈利性用途,但同时应遵守著作权法及其他相关法律的规定,不得侵犯相关权利人及本网站的合法权利。
3、本网站内容原作者如不愿意在本网站刊登内容,请及时通知本站(javaclubcn@163.com),我们将第一时间核实后及时予以删除。





本文链接:https://www.javaxia.com/server/125194.html

分享给朋友: