关于serialVersionUID
在Loong(我们公司自己开发的基于OSGI的网络应用服务器平台)中集成Glassfish 的数据源时遇到了序列化的问题:在Glassfish中序列化的连接池对象,在Loong里面反序列化时总是不成功!后来查了相关资料,原来是连接池类出了问题:只实现了Serializable接口,没有指定具体的serialVersionUID。
凡是实现Serializable接口的类都应当有一个表示序列化版本标识符的静态变量:
类的serialVersionUID的默认值完全依赖于Java编译器的实现,对于同一个类,用不同的Java编译器编译,有可能会导致不同的serialVersionUID,也有可能相同。为了提高哦啊serialVersionUID的独立性和确定性,强烈建议 在一个可序列化类中显示的定义serialVersionUID,为它赋予明确的值。
显式地定义serialVersionUID有两种用途:
1)
在某些场合,希望类的不同版本对序列化兼容,因此需要确保类的不同版本具有相同的serialVersionUID;
2)
在某些场合,不希望类的不同版本对序列化兼容,因此需要确保类的不同版本具有不同的serialVersionUID。
注意实现Externalizable接口的类,在发序列化时,将会执行构造函数,因为对于流操作而言,此对象是有明确类型的(Serializable接口是个标记接口).
而且,如果实现了writeExternal和readExternal,将不会在执行readObject和writeObject,因为此时这两个方法已经被"擦除".
对于java序列化和反序列化,被序列化的类中有关于serialVersionUID会带来一些问题;
1) 如果你调整了Class结构(比如新增/去除某个属性值,但是不能引入编译错误),但没有修改serialVersionUID;那么在反序列化和序列化时不会带来异常,只是可能导致部分属性在get时为null.
2) 如果你调整了Class结构,同时也修改了serialVersionUID;如果序列化和反序列双方没有保持uid一致的话,将会直接导致反序列化异常.(java.io.InvalidClassException)
3) 如果你没有显式的声明serialVersionUID,那么对于JVM而言,不同的class类结构(属性列表和方法列表)将会得出不同的uid;因此如果序列化双方不能保持一致的uid,仍然会带来问题.
原文:http://www.cnblogs.com/forstudy556/p/3558860.html