对序列化进行刨根问底
对序列化进行刨根问底
深谷不见幽兰 发表于4年前
对序列化进行刨根问底
  • 发表于 4年前
  • 阅读 27
  • 收藏 1
  • 点赞 0
  • 评论 0

我们编写一个实现了Serializable接口(序列化标志接口)的类,Eclipse马上就会给一个黄色警告:需要增加一个Serial Version ID.为什么要增加?它是怎么计算出来的?有什么用?下面我们来解释一下。

类实现Serializable接口的目的是为了可持续化,比如网络传输或本地存储,为系统的分布和异构部署提供先决支持条件。若是没有序列化,现在我们熟悉的远程调用、对象数据库都不可能存在,我们来看一个简单的序列化类:

public class Person implements Serializable{

private String name;

/*name属性的get/set方法省略*/

}

这是一个简单的javabean,实现了Serializable接口,可以在网络上传输,也可以本地存储然后读取。这里我们以java的消息服务方式传递对象(即通过网络传递一个对象),定义在消息队列中的数据类型为ObjectMessage,首先定义一个消息的生产者(Producer),代码如下:

public class Producer{

public static void main(String[] args) throws Exception{

Person person=new Person();

person.setName("死神");

//序列化,保存在磁盘上

SerializationUtils.writeObject(person);

}

}

这里引入了一个工具类SerializationUtils,其作用是对一个类进行序列化和反序列化,并存储到硬盘上,其代码如下:

public class SerializationUtils{

private static String FILE_NAME="c:\obj.bin";

//序列化

public static void writeObject(Serializable s){

try{

    ObjectOutputStream oos=new ObjectOutputStream(new FileOutputStream(FILE_NAME));

    oos.writeObject(s);

    oos.close();

}catch(Exception e){

e.printStackTrace();

}

}

public static Object readObject(){

    Object obj=null;

//反序列化

try{

    ObjectInput input=new ObjectInputStream(new FileInputStream(FILE_NAME));

obj=input.readObject();

input.close();

}catch(Exception e){

    e.printStackTrace();

}

return obj;

}

}

通过对象序列化过程,把一个对象从内存块转化为可传输的数据流,然后通过网络发送到消费者那里,并进行序列化,生成实例对象,代码如下:

public class Consumer{

public static void main(String[] args){

//反序列化

Person p=new (Person) SerializationUtils.readObject();

System,out,println("name="+p.getName);

}

}

这是一个反序列化的过程,也就是对象数据流转换为一个实例对象的过程,其运行后的输出结果为:死神。这很容易,是的,这就一个很简单的序列化和反序列化的demo。但此处隐藏一个问题:如果消息的生产者和消息的消费者所参考的类(Person)有差异,会出现何种神奇的事件呢?比如:消息的生产者中的Person类增加一个年龄的属性,而消费者没有增加该属性。为什么没有增加,因为这是分布式部署的应用。,你甚至都不知道这个应用部署在何处,特别是通过广播方式发送消息的情况,漏掉一两个订阅者也是很正常的。

在这种序列化和反序列化的类不一致的 情形下,反序列化就会报一个InvalidClassException异常,原因是序列化和反序列化所对应的类版本发生了变化,JVM不能把数据流转换为实例对象。接着刨根问底:JVM是根据什么来判断一个类版本的呢?

好问题,通过SerialVersionUID,也叫做流标识符,即类的版本定义的,它可以显示申明也可以隐式申明。显示申明格式如下:

private static final long serialVersionUID=xxxxxxL;

而隐式申明则是我不申明。你编译器在编译的时候帮我生成。生成的依据是通过包名、类名、继承关系、非私有的方法和属性,以及参数、返回值等诸多因子计算得出的,极度复杂,基本上计算出来的这个值是唯一的。

    serialVersionUID 如何生成已经说明了,那我们再来看看serialVersionUID的作用。JVM在反序列化时,会比较数据流中的serialVersionUID与类的serialversionUID是否相同,如果相同,则认为类没有发生改变,可以把数据流load为实例对象,如果不相同,对不起,我JVM不干了,抛出个异常InvalidClassExeception给你瞧瞧。这是一个非常好的校验机制,可以保证一个对象即使在网络或磁盘中国“滚过”一次,任然能做到“出淤泥而不染”,完美的实现类的一致性。

 但是,有时候我们需要一点特例场景,例如:我的类改变不大,JVM撒谎说“我的 版本没有变更”,如此,我们编写的类就实现了向上兼容。我们修改一下上面的Person类,代码如下:

public class Person implements Serializable{

private static final long serialVersonUID =55799L;

/*其它保持不变*/

刚开始生产者和消费者持有Person类版本一致,都是V1.0,某天生产者的Person类版本变更了,增加了一个年龄的属性,升级为V2.0版本,而由于种种原因消费者端的Person还是以前的版本,代码如下:

public class Person implements Serializable{

private static final long serialVersionUID =5799L;

/*age、name的get和set方法省略*/


}

}

此时虽然生产者和消费者对应的类版本不同,但是显示声明的serialVersionUID相同,反序列化也是可以运行的,所带来的业务问题就是消费者端不能读取新增的业务属性(age而已)

通过此例,我们的反序列化实现了版本的向上兼容的功能,所以我们在编写序列化类代码时,随手加上serialversionUID字段,也不会给我们带来太多的工作量,但它却可以在关键的时候发挥异乎寻常的作用。

共有 人打赏支持
粉丝 3
博文 49
码字总数 12345
×
深谷不见幽兰
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: