Java序列化就是把Java对象按一定方式变成字节流,并且可以从该字节流中通过反向生成原本的对象。要想让一个对象可以序列化很简单,只需要在对象声明里加入implements Serializable即可,但因为它是如此的简单以致有很多人对此产生了误解,以为只要简单加上这段声明即可,却不知道这个简单的背后是要付出代价的
代价之一:一旦一个类被发布,则"改变这个类的实现"的灵活性将大大降低. 一但你声明了一个类可序列化,在你导出的API中就包含了系列化的定义,如果这个类已经被广泛应用的话,这就意味着以后不论你对该类作何修改,你都要支持原来的反序列化方式,才不会出现无法将之前老版本对象序列批后的字节流重新组装成对象的错误.
代价之二:增加了BUG和安全漏洞的可能性. 序列化是构造对象的另一种方式,可以通过反序列化组装一个对象也就意味可以绕过构造函数来创建一个新的对象,这也意味着存在被攻击的可能性
代价之三:随着一个类的新版本的发行,相关的测试负担增加了. 正如第一点说的, 一个新版本的发布要保证它和原老版本要能够相互序列化与反序列化,因而这个测试工作量与类的数量*版本数成正比
支持序列化的一个初衷是实现对象的传输或者持久化,但从Java1.4发行版本开始,有了一种基于XML的JavaBean持久化机制,所以,对于Beans来说,实现Serializable不再是必需的了
考虑使用自定义的序列化形式
如果一个对象的物理表示等同于它的逻辑内容,则默认的序列化形式可能是合适的,即使如此,通常仍然要提供一个readObject方法以保证约束关系和安全性.即还要重写readObject方法来保证读到的字节流组装成的对象的域符合原对象所定义的约束关系,防止通过修改序列化字节流来篡改伪造对象
当一个对象的物理表示与它的逻辑数据内容有实质性的区别时,使用默认序列化形式有4个缺点:
1. 它使这个类的导出API永久地束缚在该类的内部表示上
2.它要消耗过多的空间.
3. 它要消耗过多的时间.默认序列化是一个图遍历过程
4. 它会引起栈举出. 默认的序列化过程要对对象图执行一次递归遍历,即使对于中等规模的对象图,这样的操作也可能会引起栈溢出
保护性地编写readObject方法
readObject可以看成是另一个公有的构造函数,它读取字节流,产生新对象,因而如果有必要请对readObject中的参数进行保护性拷贝,这样可以避免攻击者通过修改序列化后的字节流来制造不符合构造约束的对象。下面的原则有助于编写一个更健壮的readObject方法:
1.对于对象引用域必须保持为私有的类,对“将被保存到这些域中的对象”进行保护性拷贝。非可变类的可变组件就属于这一类别。
2.对于具有约束条件的类,一定要检查约束条件是否满足,如果不满足的话,则抛出一个InvalidObjectException异常。这些检查动作应该跟在所有的保护性拷贝之后。
3.如果在对象图被反序列化之后,整个对象图必须都是有效的,则应该使用ObjectInputValidation接口。
4.无论是直接方式还是间接方式,都不要调用类中可被改写的方法。
必要时提供一个readResolve方法
如果一个类是单例模式,则通过生写readObject方法还是会产生一个新的实例,无法满足单例的要求,这时需要提供一个readResolve方法。
对于单例模式,只需要在readResolve方法中返回保存类实例的变量即可:
private Object readResolve() throws ObjectStreamException{
return INSTANCE;
}
对于其他情况,可以直接调用构造函数,通过构造函数中的约束来保证反序列化的约束:
private Object readResolve() throws ObjectStreamException{
return new SomeObject(var1,var2);
} |