很多商业项目用到数据库、内存映射文件和普通文件来完成项目中的序列化处理的需求,但是这些方法很少会依靠于Java序列化。本文也不是用来解释序列化的,而是一起来看看面试中有关序列化的问题,这些问题你很有可能不了解。“Java序列化指的是将对象转换程字节格式并将对象状态保存在文件中,通常是.ser扩展名的文件。然后可以通过.ser文件重新创建Java对象,这个过程为返序列化”
Java序列化的API中提供了开发人员进行序列化对象的机制,通过Serializable和Externalizable接口。
一起看看这些问题:
1)Java中的Serializable接口和Externalizable接口有什么区别?
这个是面试中关于Java序列化问的最多的问题。我的回答是,Externalizable接口提供了两个方法writeExternal()和readExternal()。这两个方法给我们提供了灵活处理Java序列化的方法,通过实现这个接口中的两个方法进行对象序列化可以替代Java中默认的序列化方法。正确的实现Externalizable接口可以大幅度的提高应用程序的性能。
2)Serializable接口中有借个方法?如果没有方法的话,那么这么设计Serializable接口的目的是什么?
Serializable接口在java.lang包中,是Java序列化机制的核心组成部分。它里面没有包含任何方法,我们称这样的接口为标识接口。如果你的类实现了Serializable接口,这意味着你的类被打上了“可以进行序列化”的标签,并且也给了编译器指示,可以使用序列化机制对这个对象进行序列化处理。
3)什么是serialVersionUID?如果你没有定义serialVersionUID意味着什么?
SerialVersionUID应该是你的类中的一个public static final类型的常量,如果你的类中没有定义的话,那么编译器将抛出警告。如果你的类中没有制定serialVersionUID,那么Java编译器会根据类的成员变量和一定的算法生成用来表达对象的serialVersionUID ,通常是用来表示类的哈希值(hash code)。结论是,如果你的类没有实现SerialVersionUID,那么如果你的类中如果加入或者改变成员变量,那么已经序列化的对象将无法反序列化。这是以为,类的成员变量的改变意味这编译器生成的SerialVersionUID的值不同。Java序列化过程是通过正确SerialVersionUID来对已经序列化的对象进行状态恢复。
4)当对象进行序列化的时候,如果你不希望你的成员变量进行序列化,你怎么办?
这个问题也会这么问,如何使用暂态类型的成员变量?暂态和静态成员变量是否会被序列化等等。如果你不希望你的对象中的成员变量的状态得以保存,你可以根据需求选择transient或者static类型的变量,这样的变量不参与Java序列化处理的过程。
5)如果一个类中的成员变量是其它符合类型的Java类,而这个类没有实现Serializable接口,那么当对象序列化的时候会怎样?
如果你的一个对象进行序列化,而这个对象中包含另外一个引用类型的成员编程,而这个引用的类没有实现Serializable接口,那么当对象进行序列化的时候会抛出“NotSerializableException“的运行时异常。
6)如果一个类是可序列化的,而他的超类没有,那么当进行反序列化的时候,那些从超类继承的实例变量的值是什么?
Java中的序列化处理实例变量只会在所有实现了Serializable接口的继承支路上展开。所以当一个类进行反序列化处理的时候,超类没有实现Serializable接口,那么从超类继承的实例变量会通过为实现序列化接口的超类的构造函数进行初始化。
7) Can you Customize Serialization process or can you override default Serialization process in Java?
7)你能够自定义序列化处理的代码吗或者你能重载Java中默认的序列化方法吗?
答案是肯定的,可以。我们都知道可以通过ObjectOutputStream中的writeObject()方法写入序列化对象,通过ObjectInputStream中的readObject()读入反序列化的对象。这些都是Java虚拟机提供给你的两个方法。如果你在你的类中定义了这两个方法,那么JVM就会用你的方法代替原有默认的序列化机制的方法。你可以通过这样的方式类自定义序列化和反序列化的行为。需要注意的一点是,最好将这两个方法定义为private,以防止他们被继承、重写和重载。也只有JVM可以访问到你的类中所有的私有方法,你不用担心方法私有不会被调用到,Java序列化过程会正常工作。
8)假设一个新的类的超类实现了Serializable接口,那么如何让这个新的子类不被序列化?
如果一个超类已经序列化了,那么无法通过是否实现什么接口的方式再避免序列化的过程了,但是也还有一种方式可以使用。那就是需要你在你的类中重新实现writeObject()和readObject()方法,并在方法实现中通过抛出NotSerializableException。
9)在Java进行序列化和反序列化处理的时候,哪些方法被使用了?
这个是面试中常见的问题,主要用来考察你是否对readObject()、writeObject()、readExternal()和writeExternal()方法的使用熟悉。Java序列化是通过java.io.ObjectOutputStream这个类来完成的。这个类是一个过滤器流,这个类完成对底层字节流的包装来进行序列化处理。我们通过ObjectOutputStream.writeObject(obj)进行序列化,通过ObjectInputStream.readObject()进行反序列化。对writeObject()方法的调用会触发Java中的序列化机制。readObject()方法用来将已经持久化的字节数据反向创建Java对象,该方法返回Object类型,需要强制转换成你需要的正确类型。
10) Suppose you have a class which you serialized it and stored in persistence and later modified that class to add a new field. What will happen if you deserialize the object already serialized?
10)假设你有一个类并且已经将这个类的某一个对象序列化存储了,那么如果你在这个类中加入了新的成员变量,那么在反序列化刚才那个已经存在的对象的时候会怎么样?
这个取决于这个类是否有serialVersionUID成员。通过上面的,我们已经知道如果你的类没有提供serialVersionUID,那么编译器会自动生成,而这个serialVersionUID就是对象的hash code值。那么如果加入新的成员变量,重新生成的serialVersionUID将和之前的不同,那么在进行反序列化的时候就会产生java.io.InvalidClassException的异常。这就是为什么要建议为你的代码加入serialVersionUID的原因所在了。
11)JAVA反序列化时会将NULL值变成""字符!!
------------------------------------------------------------------------------------------------------------------------------
Java的序列化和反序列化总结
- 把Java对象转换为字节序列的过程称为对象的序列化。
- 把字节序列恢复为Java对象的过程称为对象的反序列化。
- java中引入序列化机制主要是为了支持两种重要技术:RMI和JavaBean技术。
- 对象的序列化主要有两种用途:
1) 把对象的字节序列永久地保存到硬盘上,通常存放在一个文件中;
2) 在网络上传送对象的字节序列。
- 只有实现了Serializable和Externalizable接口的类的对象才能被序列化。
1)Serializable接口可使类中的所有成员变量自动被序列化(transient和static修饰的变量除外),默认的
序列化方式会序列化整个对象图,这需要递归遍历对象图。如果对象图很复杂,递归遍历操作需要消耗很多
的空间和时间,它的内部数据结构为双向列表。在应用时,如果对某些成员变量都改为transient类型,将
节省空间和时间,提高序列化的性能。
2)Externalizable接口继承自Serializable接口,实现Externalizable接口的类完全由自身来控制序列化
的行为,即Externalizable对象默认情况下不保存任何它的字段,而仅实现Serializable接口的类可以
采用默认的序列化方式 。
那我们如何对一个Serializable对象的序列化和反序列化行为进行控制呢?
1)加transient修饰符,这样改变量就不会被序列化了
2)添加(不是“实现”和“重载” )writeObject和readObject方法: private void writeObject(ObjectOutputStream stream) throws IOException; private void readObject(ObjectOutputStream stream) throws IOException; 这样一旦对象被序列化或者被反序列化,就会自动分别调用这两个方法,而不会调用默认的序列化和反序列化方法。(这一点确实感觉有点奇怪,或者叫混乱!) 当ObjectOutputStream对一个Serializable对象进行序列化时,如果该对象具有writeObject()方法,那么就会执行这一方法,否则就按默认方式序列化。在该对象的writeObjectt()方法中,可以先调用ObjectOutputStream的defaultWriteObject()方法,使得对象输出流先执行默认的序列化操作。同理可得出反序列化的情况,不过这次是defaultReadObject()方法。
- 对Serializable对象反序列化时,并不会调用任何构造函数 ,因此Serializable类无需默认构造函数,但是当Serializable类的父类没有实现Serializable接口时,反序列化过程会调用父类的默认构造函数,因此该父类必需有默认构造函数,否则会抛异常。
- 对Externalizable对象反序列化时,会先调用类的不带参数的构造方法 ,这是有别于默认反序列方式的。如果把类的不带参数的构造方法删除,或者把该构造方法的访问权限设置为private、默认或protected级别,会抛出java.io.InvalidException: no valid constructor异常,因此Externalizable对象必须有默认构造函数,而且必需是public的。
- 对象序列化包括如下步骤: 1) 创建一个对象输出流,它可以包装一个其他类型的目标输出流,如文件输出流; 2) 通过对象输出流的writeObject()方法写对象。
- 对象反序列化的步骤如下: 1) 创建一个对象输入流,它可以包装一个其他类型的源输入流,如文件输入流; 2) 通过对象输入流的readObject()方法读取对象。 下面是个简单的例子: import java.io.*; import java.util.Date; public class Test{ public static void main(String[] args) throws Exception { //序列化对象 ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream("c:/objectFile.data")); MyObject obj1= new MyObject("liuhongliang", 24); out.writeObject("hello world!"); out.writeObject(new Date()); out.writeObject(obj1); out.writeInt(54); out.close(); //反序列化对象 ObjectInputStream in = new ObjectInputStream( new FileInputStream(("c:/objectFile.data")); System.out.println("obj1=" + (String) in.readObject()); System.out.println("obj2=" + (Date) in.readObject()); MyObject obj3 = (MyObject) in.readObject(); System.out.println("obj3=" + obj3); int obj4 = in.readInt(); System.out.println("obj4=" + obj4); in.close(); } } //自定义可序列化类 class MyObject implements Serializable { private String name; private int age; public MyObject(String name, int age) { this.name = name; this.age = age; } public String toString() { return "name=" + name + ", age=" + age; } }
-
关于serialVersionUID
在Loong(我们公司自己开发的基于OSGI的网络应用服务器平台)中集成Glassfish 的数据源时遇到了序列化的问题:在Glassfish中序列化的连接池对象,在Loong里面反序列化时总是不成功!后来查了相关资料,原来是连接池类出了问题:只实现了Serializable接口,没有指定具体的serialVersionUID。
凡是实现Serializable接口的类都应当有一个表示序列化版本标识符的静态变量:
private static final long serialVersionUID; 以上serialVersionUID的取值是Java运行时环境根据类的内部细节自动生成的。如果对类的源代码作了修改,再重新编译,新生成的类文件的serialVersionUID的取值有可能也会发生变化。
类的serialVersionUID的默认值完全依赖于Java编译器的实现,对于同一个类,用不同的Java编译器编译,有可能会导致不同的serialVersionUID,也有可能相同。为了提高哦啊serialVersionUID的独立性和确定性,强烈建议 在一个可序列化类中显示的定义serialVersionUID,为它赋予明确的值。
显式地定义serialVersionUID有两种用途:
1) 在某些场合,希望类的不同版本对序列化兼容,因此需要确保类的不同版本具有相同的serialVersionUID;
2) 在某些场合,不希望类的不同版本对序列化兼容,因此需要确保类的不同版本具有不同的serialVersionUID。
- 利用java的序列化和反序列化机制可以实现对任何可Serializable的对象的深度复制
上面的例子里,现将MyObject对象序列化到硬盘文件 c:/objectFile.data,然后反序列化之,这样可以实现深度复制,但是由于操作硬盘,所以当该操作比较频繁时会严重影响系统性能,上面是用文件流方式的实现,我们可以用字节流方式来高效的实现深度复制: import java.io.*; import java.util.Date; public class Test2 { public static void main(String[] args) throws Exception { //序列化对象 ObjectOutputStream out = new ObjectOutputStream( new ByteArrayOutputStream()); MyObject obj1= new MyObject("liuhongliang", 24); out.writeObject("hello world!"); out.writeObject(new Date()); out.writeObject(obj1); out.writeInt(54); out.close(); //反序列化对象 ObjectInputStream in = new ObjectInputStream( new ByteArrayInputStream(out.toByteArray())); System.out.println("obj1=" + (String) in.readObject()); System.out.println("obj2=" + (Date) in.readObject()); MyObject obj3 = (MyObject) in.readObject(); System.out.println("obj3=" + obj3); int obj4 = in.readInt(); System.out.println("obj4=" + obj4); in.close(); } } //自定义可序列化类 class MyObject implements Serializable { private String name; private int age; public MyObject(String name, int age) { this.name = name; this.age = age; } public String toString() { return "name=" + name + ", age=" + age; } }
-----------------------------------------------------------------------------------------------------------------------
serialVersionUID的作用
当我们的类实现了Serializable接口后,会有一个警告,告诉你需要生成一个serialVersionUID属性。这个serialVersionUID是做什么用的呢?其实这是JAVA序列化的版本控制功能。当序列化对象时会把这个属性写入,当反序列化时则会把这个属性取出,然后与JAVA类中的serialVersionUID属性值对比,如果一致,则认为是同一个版本,正常反序列化,如果不一致则认为版本不同,抛出InvalidClassException异常。
很多时候我们忽略这个警告,并不写这个serialVersionUID属性,但仍然可以正常序列化。那是因为如果没有这个属性,JVM将会根据这个类的属性和方法,计算出一个值作为serialVersionUID的值。这种做法会带来潜在的风险。不同的JVM产生serialVersionUID的算法可能会不一致,如果在不同的环境下产生的serialVersionUID不一致,将导致反序列化失败!
当一个类的结构发生变化,需要改变serialVersionUID,以通知序列化机制此类发生了变化,不兼容原来的版本了!其实并不是只要类结构变化,就必须更改serialVersionUID,JAVA的序列化机制提供了部分变化的兼容机制,有如下几种:
• 添加新的属性 反序列时发现没有此属性,则会赋予该属性默认的类型值
• 添加 writeObject/readObject 方法 因为此方法是用于自定义序列化,不影响序列化
• 删除 writeObject/readObject 方法 同上原因
• 改变属性的访问权限(private protected package public)
• 将一个属性从static变为nonstatic 或者 transient 或者 nontransient
如果你的类改动属于以上范围,默认的JAVA序列化机制可以保证兼容性,也就是说你不需要改动serialVersionUID值。
更多情况参见http://java.sun.com/j2se/1.4/pdf/serial-spec.pdf 5.6.2 Compatible Changes
:要想将父类对象也序列化,就需要让父类也实现Serializable 接口。如果父类不实现的话的,就 需要有默认的无参的构造函数。 在父类没有实现 Serializable 接口时,虚拟机是不会序列化父对象的,而一个 Java 对象的构造必须先有父对象,才有子对象,反序列化也不例外。所以反序列化时,为了构造父对象,只能调用父类的无参构造函数作为默认的父对象。因此当我们取 父对象的变量值时,它的值是调用父类无参构造函数后的值。如果你考虑到这种序列化的情况,在父类无参构造函数中对变量进行初始化,否则的话,父类变量值都 是默认声明的值,如 int 型的默认是 0,string 型的默认是 null。
Transient 关键字的作用是控制变量的序列化,在变量声明前加上该关键字,可以阻止该变量被序列化到文件中,在被反序列化后,transient 变量的值被设为初始值,如 int 型的是 0,对象型的是 null。