学习笔记之序列化

最近使用MFC的序列化来实现数据保存和加载的功能，感觉到MFC的强大，让我们如此轻松地实现这个功能。在使用的时候遇到一些疑问，经过搜索，找到了一篇Java上的序列化文章，但是精神上是一致的，在此做一些摘录

 

(原文在http://www.360doc.com/content/06/0727/14/10041_166035.shtml)

 

摘录：

 

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

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

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

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

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

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

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

 

 

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

不要兼容性：

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

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

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

    private static final long serialVersionUID=????;

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

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

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

 

 

讨论一下兼容性策略：

       到这里我们可以看到要保持向下的兼容性很麻烦。而且随着版本数目的增加。维护会变得困难而繁琐。讨论什么样的程序应该使用怎么样的兼容性序列化策略已经超出本文的范畴，但是对于一个游戏的存盘功能，和对于一个字处理软件的文档的兼容性的要求肯定不同。对于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()。

    所以我的建议是：一般情况下，只有对于final的类采用readResolve()来进行保护。