谈谈J2SE中的序列化

java中处处体现着简单的程序设计风格，序列化作为最常用的功能之一，在java中的设计尤为“简单”。在ObjectInputStream 和ObjectOutputStream的帮助下，我们可以轻松的实现序列化。

只要我们的class 实现了java.io.Serializable接口，就可以利用ObjectOutputStream的writeObject（）方法将一个对象序列化；利用ObjectInputStream的readObject()方法，可以返回读出的object对象。Serializable接口不需要我们实现任何方法。

以下是一个例子，它能给我们一个感性的认识：

Serial实现了就java.io.Serializable接口，是需要序列化的类。我们首先构造一个Serial的对象serial1然后将其保存(序列化)在一个文件中，而后再将其读出（反序列化），并打印其内容。

package Stream;
/**
* @author favo yang
*/

import java.io.*;
public class Serial implements Serializable {
int company_id;
String company_addr;
boolean company_flag;
public Serial(){}//不同于c++,没有也可以
public Serial(int company_id,String company_addr,boolean company_flag) {
this.company_id=company_id;
this.company_addr=company_addr;
this.company_flag=company_flag;
}
public static void main(String[] args) {
Serial serial1 = new Serial(752,"dayer street #5 building 02-287",false);
//构造一个新的对象
FileInputStream in=null;
FileOutputStream out=null;
ObjectInputStream oin=null;
ObjectOutputStream oout=null;
try {
out = new FileOutputStream("5.txt");
oout = new ObjectOutputStream(out);
serial1.serialize(oout);//序列化
oout.close();
oout=null;
in = new FileInputStream("5.txt");
oin = new ObjectInputStream(in);
Serial serial2 = Serial.deserialize(oin);//反序列化
System.out.println(serial2);//打印结果
} catch (Exception ex){
ex.printStackTrace();
} finally{
try {
if (in != null) {
in.close();
}
if (oin != null) {
oin.close();
}
if (out != null) {
out.close();
}
if (oout != null) {
oout.close();
}
} catch (IOException ex1) {
ex1.printStackTrace();
}
}
}

/**
* deserialize
*/
public static Serial deserialize(ObjectInputStream oin) throws Exception{
Serial s=(Serial)oin.readObject();
return s;
}

public String toString() {
return "DATA: "+company_id+" "+company_addr+" "+company_flag;
}

/**
* serialize
*/
public void serialize(ObjectOutputStream oout) throws Exception{
oout.writeObject(this);
}
}

运行结果：

DATA: 752 dayer street #5 building 02-287 false
正确打印了结果。

现在序列化的功能还没有被j2me支持，所以我们在j2me中是使用DataInputStream、DataoutputStream配合rms或者网络实现序列化。详细的介绍请参见：本站的另外两篇文章：《Java的基本数据类型与流》、
《J2ME联网中采用序列化机制》

了解序列化带来的风险与问题

我们已经看到了序列化的优点，就是简单的序列化的实现成本很低，或者说没有什么实现成本，只要实现一个接口就行了。但如果你将上文中的那个例子简单的套用在你的程序中，然后发表的话，你可有苦头了。你将会很快发现序列化带来问题：

1.实现了Serializable接口的类的改动变得很难（兼容性问题）。
如果你想保持向下兼容性的话，这意味着要求新版本反序列化老版本序列化的数据流；如果你想保持向上兼容性的话，这意味着要求老版本反序列化新版本的数据流。尤其是向下兼容性的问题带来了让我们的代码实现很难改动的问题，为了能在新版本中反序列化老版本的数据流，类的实现必须要保留老版本的实现过程。这无疑是我们给自己加带上的一副枷锁。

2.实现了Serializable接口的类的测试成本大大增加了
可以想象，当新版本发布时，为了保持兼容性，你的测试量将是版本数的平方！

3.草率的接受默认的序列化方式可能会带来性能问题，甚至更糟。
序列化作为额外的一种“构造函数”可能破坏数据的完整性、约束性，甚至，一个精心伪造的数据流所序列化出的对象可能带来安全隐患。

了解了这些可能的风险后，我们在序列化的时候遇到了难题，如何避免这些风险呢？我将这些风险概括为以下几个方面：

1. 当序列化遇到继承时引发的问题？
2. 何时接受默认的java序列化？
3. 兼容性问题
4. 数据一致性问题与数据约束问题
5. 安全性问题

如何应对这些风险呢？请关注接下来的内容。

当序列化遇到继承…
当一个父类实现Serializable接口后，他的子类都将自动的实现序列化。

以下验证了这一点：

package Serial;
import java.io.Serializable;
public class SuperC implements Serializable {//父类实现了序列化
int supervalue;
public SuperC(int supervalue) {
this.supervalue = supervalue;
}
public String toString() {
return "supervalue: "+supervalue;
}
}

public class SubC extends SuperC {//子类
int subvalue;

public SubC(int supervalue,int subvalue) {
super(supervalue);
this.subvalue=subvalue;
}

public String toString() {
return super.toString()+" sub: "+subvalue;
}
}

public class Test1 {

public static void main(String [] args){
SubC subc=new SubC(100,200);
FileInputStream in=null;
FileOutputStream out=null;
ObjectInputStream oin=null;
ObjectOutputStream oout=null;
try {
out = new FileOutputStream("Test1.txt");//子类序列化
oout = new ObjectOutputStream(out);
oout.writeObject(subc);
oout.close();
oout=null;

in = new FileInputStream("Test1.txt");
oin = new ObjectInputStream(in);
SubC subc2=(SubC)oin.readObject();//子类反序列化
System.out.println(subc2);
} catch (Exception ex){
ex.printStackTrace();
} finally{
…此处省略
}
}
}

运行结果如下：

supervalue: 100 sub: 200

可见子类成功的序列化/反序列化了。

怎管让子类实现序列化看起来是一件很简单的事情，但有的时候，往往我们不能够让父类实现Serializable接口，原因是有时候父类是抽象的（这并没有关系），并且父类不能够强制每个子类都拥有序列化的能力。换句话说父类设计的目的仅仅是为了被继承。

要为一个没有实现Serializable接口的父类，编写一个能够序列化的子类是一件很麻烦的事情。java docs中提到：

“To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype's public, protected, and (if accessible) package fields. The subtype may assume this responsibility only if the class it extends has an accessible no-arg constructor to initialize the class's state. It is an error to declare a class Serializable if this is not the case. The error will be detected at runtime. ”

也就是说，要为一个没有实现Serializable接口的父类，编写一个能够序列化的子类要做两件事情：

其一，父类要有一个无参的constructor；

其二，子类要负责序列化（反序列化）父类的域。

我们将SuperC的Serializable接口去掉，而给SubC加上Serializable接口。运行后产生错误：

java.lang.Error: Unresolved compilation problem:
Serializable cannot be resolved or is not a valid superinterface
at Serial.SubC.<init>(SubC.java:15)
at Serial.Test1.main(Test1.java:19)
Exception in thread "main"

果真如docs中所说的一样，父类缺少无参构造函数是不行的。

接下来，按照docs中的建议我们改写这个例子：
public abstract class SuperC {
int supervalue;
public SuperC(int supervalue) {
this.supervalue = supervalue;
}
public SuperC(){}//增加一个无参的constructor
public String toString() {
return "supervalue: "+supervalue;
}
}

public class SubC extends SuperC implements Serializable {
int subvalue;

public SubC(int supervalue,int subvalue) {
super(supervalue);
this.subvalue=subvalue;
}

public String toString() {
return super.toString()+" sub: "+subvalue;
}

private void writeObject(java.io.ObjectOutputStream out)
throws IOException{
out.defaultWriteObject();//先序列化对象
out.writeInt(supervalue);//再序列化父类的域
}
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException{
in.defaultReadObject();//先反序列化对象
supervalue=in.readInt();//再反序列化父类的域
}
}

运行结果证明了这种方法是正确的。在此处我们用到了writeObject/ readObject方法，这对方法如果存在的话，序列化时就会被调用，以代替默认的行为（以后还要探讨，先了解这么多）。我们在序列化时，首先调用了ObjectOutputStream的defaultWriteObject，它使用默认的序列化行为，然后序列化父类的域；反序列化的时候也一样。

归纳一下：

目的 行为
为一个实现Serializable接口的父类，编写一个能够序列化的子类 子类将自动的实现序列化
为一个没有实现Serializable接口的父类，编写一个能够序列化的子类 1， 父类要有一个无参的constructor；2， 子类要先序列化自身，然后子类要负责序列化父类的域

何时接受默认的java序列化行为

首先要了解java默认的序列化行为，java将一切关于对象的信息都保存了下了，也就是说，有些时候那些不需要保存的也被保存了下来。一般情况下，我们仅仅需要保存逻辑数据就可以了。不需要保存的数据我们可以用关键字transient标出。

以下是一个例子：

import java.io.*;

public class Serial implements Serializable {

int company_id;

String company_addr;

transient boolean company_flag;

}

则company_flag字段将不会参与序列化与反序列化，但同时你也增加了为他初始值的责任。这也是序列化常常导致的问题之一。因为序列化相当于一个只接受数据流的public构造函数，这种对象构造方法是语言之外的。但他仍然是一种形式上的构造函数。如若你的类不能够通过其他方面来保证初始化，则你需要额外的提供readObject方法，首先正常的反序列化，然后对transient标示的字段进行初始化。

在不适合的时候，使用java默认的序列化行为可能会带来速度上的影响，最糟糕的情况是，可能导致溢出。在某些数据结构的实现中，经常会充斥着各种的循环引用，而java的默认序列化行为，并不了解你的对象结构，其结果就是java试图通过一种昂贵的“图遍历”来保存对象状态。可想而知，不但慢而且可能溢出。这时候你就要提供自己的readObject，来代替默认的行为。

兼容性问题
兼容性历来是复杂而麻烦的问题。

不要兼容性：

首先来看看如果我们的目的是不要兼容性，应该注意哪些。不要兼容性的场合很多，比如war3每当版本升级就不能够读取以前的replays。

兼容也就是版本控制，java通过一个名为UID（stream unique identifier）来控制，这个UID是隐式的，它通过类名，方法名等诸多因素经过计算而得，理论上是一一映射的关系，也就是唯一的。如果UID不一样的话，就无法实现反序列化了，并且将会得到InvalidClassException。

当我们要人为的产生一个新的版本（实现并没有改动），而抛弃以前的版本的话，可以通过显式的声名UID来实现：

private static final long serialVersionUID=????;

你可以编造一个版本号，但注意不要重复。这样在反序列化的时候老版本将得到InvalidClassException，我们可以在老版本的地方捕捉这个异常，并提示用户升级的新的版本。

当改动不大时，保持兼容性（向下兼容性的一个特例）：

有时候你的类增加了一些无关紧要的非私有方法，而逻辑字段并不改变的时候，你当然希望老版本和新版本保持兼容性，方法同样是通过显式的声名UID来实现。下面我们验证一下。

老版本：

import java.io.*;

public class Serial implements Serializable {

int company_id;

String company_addr;

public Serial1(int company_id, String company_addr) {
this.company_id = company_id;
this.company_addr = company_addr;
}

public String toString() {
return "DATA: "+company_id+" "+company_addr;
}

}

新版本

import java.io.*;

public class Serial implements Serializable {

int company_id;
String company_addr;

public Serial1(int company_id, String company_addr) {
this.company_id = company_id;
this.company_addr = company_addr;
}

public String toString() {
return "DATA: "+company_id+" "+ company_addr;
}
public void todo(){}//无关紧要的方法

}

首先将老版本序列化，然后用新版本读出，发生错误：

java.io.InvalidClassException: Serial.Serial1; local class incompatible: stream classdesc serialVersionUID = 762508508425139227, local class serialVersionUID = 1187169935661445676

接下来我们加入显式的声名UID：

private static final long serialVersionUID=762508508425139227l;

再次运行，顺利地产生新对象

DATA: 1001 com1

如何保持向上兼容性：

向上兼容性是指老的版本能够读取新的版本序列化的数据流。常常出现在我们的服务器的数据更新了，仍然希望老的客户端能够支持反序列化新的数据流，直到其更新到新的版本。可以说，这是半自动的事情。

跟一般的讲，因为在java中serialVersionUID是唯一控制着能否反序列化成功的标志，只要这个值不一样，就无法反序列化成功。但只要这个值相同，无论如何都将反序列化，在这个过程中，对于向上兼容性，新数据流中的多余的内容将会被忽略；对于向下兼容性而言，旧的数据流中所包含的所有内容都将会被恢复，新版本的类中没有涉及到的部分将保持默认值。利用这一特性，可以说，只要我们认为的保持serialVersionUID不变，向上兼容性是自动实现的。

当然，一但我们将新版本中的老的内容拿掉，情况就不同了，即使UID保持不变，会引发异常。正是因为这一点，我们要牢记一个类一旦实现了序列化又要保持向上下兼容性，就不可以随随便便的修改了！！！

测试也证明了这一点，有兴趣的读者可以自己试一试。

如何保持向下兼容性：

一如上文所指出的，你会想当然的认为只要保持serialVersionUID不变，向下兼容性是自动实现的。但实际上，向下兼容要复杂一些。这是因为，我们必须要对那些没有初始化的字段负责。要保证它们能被使用。

所以必须要利用
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException{
in.defaultReadObject();//先反序列化对象
if（ver=5552）{//以前的版本5552
…初始化其他字段
}else if（ver=5550）{//以前的版本5550
…初始化其他字段
}else{//太老的版本不支持
throw new InvalidClassException();
}
}
细心的读者会注意到要保证in.defaultReadObject();能够顺利执行，就必须要求serialVersionUID保持一致，所以这里的ver不能够利用serialVersionUID了。这里的ver是一个我们预先安插好的final long ver=xxxx;并且它不能够被transient修饰。所以保持向下的兼容性至少有三点要求：

1.serialVersionUID保持一致
2.预先安插好我们自己的版本识别标志的final long ver=xxxx;
3.保证初始化所有的域

讨论一下兼容性策略：

到这里我们可以看到要保持向下的兼容性很麻烦。而且随着版本数目的增加。维护会变得困难而繁琐。讨论什么样的程序应该使用怎么样的兼容性序列化策略已经超出本文的范畴，但是对于一个游戏的存盘功能，和对于一个字处理软件的文档的兼容性的要求肯定不同。对于rpg游戏的存盘功能，一般要求能够保持向下兼容，这里如果使用java序列化的方法，则可根据以上分析的三点进行准备。对于这样的情况使用对象序列化方法还是可以应付的。对于一个字处理软件的文档的兼容性要求颇高，一般情况下的策略都是要求良好的向下兼容性，和尽可能的向上兼容性。则一般不会使用对象序列化技术，一个精心设计的文档结构，更能解决问题。

数据一致性问题、约束问题
要知道序列化是另一种形式上的“public构造函数”，但他仅仅构造起对象，而不作任何的检查，这样人很不舒服，所以必要的检查是必须的，这利用了readObject()

private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException{
in.defaultReadObject();//先反序列化对象
…进行检查与初始化
}

出于结构化的考虑，通常使用一个名为initialize的函数，负责检查与初始化，如果失败抛出异常。要保持检查与初始化是很容易被忘记的，这常常导致问题。另一个问题在于当父类没有加入readObject()的时候，子类很容易忘记要调用对应的initialize函数。这仿佛回到了当初为什么要引入构造函数的问题，原因就是防止子类忘记调用初始化函数引发各种问题。所以，如果要保持数据一致性，一定要加入readObject()。

安全问题
安全性的话题超出了本文的范畴，但是你应该要知道，有可能一个攻击者会对你的类准备一个恶意的数据流企图生成一个错误的类。当你需要确保你的对象数据安全的话，你一般可以利用上面的方法来检查，并初始化，但对于某些引用不好检查。解决方法就是对重要的部件进行保护性拷贝。这里推荐一个好方法，它不用保护性拷贝个别的域，而是直接保护性拷贝整个对象。这就是：
Object readResolve() throws ObjectStreamException;
这个方法的用途就是，他会紧接着readObject()调用。它将会利用返回的对象代替原来反序列化的对象。也就是原来readObject()反序列化的对象将会被立即的丢弃。

Object readResolve() throws ObjectStreamException{

return new Serial2(this.xxx1,this.xxx2);// xxx1、xxx2是刚刚反序列化得来的，这是一种保护性拷贝

}
这样的话虽然在时间上有所浪费，但是对于特别的重要而安全的类，可以使用这种方法。如果数据一致性问题、约束问题通过逐一检查来解决很麻烦，也可以利用这种方法，但要考虑好成本，和注意下面的局限性。 利用readResolve()有一个明显的缺点，就是当父类实现了readResolve(),子类将变得无丛下手。如果一个保护的或者是公有的父类的readResolve()存在，并且子类也没有改写它，将会使得子类反序列化的时候最终得到一个父类的对象，这既不是我们要得结果，也不容易发现这种错误。而让子类重写readResolve()无疑是一个负担。也就是说对于要继承的类而言，实现readResolve()来保护类不是一个好方法。我们只能利用第一种方法写一个保护性的readObject()。