java 序列化 uid_从serialVersionUID到Java序列化

在我们的项目开发过程中,往往会有这样的要求,对于需要序列化的类, 在实现serializable接口的同时,要求在类中定义serialVersionUID.

public static final long serialVersionUID = -11222222122xxxxL;

复制代码

这时我们往往会产生疑问,这个serialVersionUID是干什么用的呢?在讨论serialVersionUID时,我们必须结合 Java 的序列化对其进行分析.

众所周知,Java的序列化机制的主要作用在于两点:

方便对内存中的对象数据进行持久化

便于对象在网络中的传输,常见应用如RPC

那么在使用序列化机制保存对象的时候,我们就需要考虑一个问题:随着应用程序的演进,序列化对象本身的定义也在发生更改,那么旧版本的程序是否还能向后兼容新的序列化对象?或者,新版程序还能否向前兼容去处理老版本的对象?

在类中定义serialVersionUID静态域就是为了Java序列化的版本兼容,为什么这么说呢?

首先,让我们回顾一下Java序列化的知识:

当序列化存储一个对象时,这个对象所属的类也必须存储.这个类的描述包含了:

类名

序列化的版本唯一的ID,也是数据域类型和方法签名的指纹( 本文所说的serialVersionUID就是这个

)

描述序列化方法的标志集

对数据域的描述

到这里,我们知道 serialVersionUID就是序列化对象的指纹

,而它的值是通过对类,超类,接口,域类型和方法签名按照规范方式排序,然后进行SHA得到的20字节长度的数据.

因此,理论上来说当对象所属的类的定义发生变化时,其serialVersionUID一定会发生变化,但是由于序列化机制只使用SHA码的前8个字节,因此不是一定发生变化,但是几率还是非常大的.

而序列化机制在读入一个对象时,会使用它的指纹与它所属的类的当前指纹进行比对,如果它们不匹配,就说明这个类的定义在该对象被写出之后发生过变化,从而会抛出 java.io.InvalidClassException

异常.

照这样来说,岂不是没法进行版本兼容了?当然不会.

Java核心技术中是这样解释的:

如果一个类具有名为serialVersionUID的静态数据成员,它就不再需要人工地计算其指纹,只需直接使用这个值

一旦这个静态数据成员被置于某个类的内部,那么序列化系统就可以读入这个类的对象的不同版本

到这里,添加serialVersionUID静态域的作用已经很清楚了.通过这一措施,可以使Java的序列化更好地进行版本控制,避免抛出java.io.InvalidClassException异常,虽然当出现数据的版本不一致时,可能会导致数据的一部分丢失,但至少保证了服务的可用.

当序列化对象与类的版本不一致时,Java序列化是如何工作的?

如果这个类只有方法发生了变化,那么在读入新对象数据时是不会有任何问题的.但是如果字段域发生了变化,那么可能出现问题,例如可能类中的字段减少或者类型的改变等等.

如果被序列化的对象具有当前版本的类中没有的成员字段(非transient,非static),那么忽略这些额外的数据

如果当前版本的类中具有序列化对象中没有的域,赋默认值