序列化下的单例模式（九耶-钛伦特）

九耶 钛伦特

九耶IT，好工作，迎接更好未来！

内容审核中

内容将在审核通过后自动发布

序列化下的单例模式

单例模式要求定义一个类时，确保这个类在虚拟机运行时创建的所有对象都是同一个对象。单例模式又分为饿汉式单例模式和懒汉式单例模式。为了保证线程安全，这里采用饿汉式单例模式来讨论在序列化和反序列化时单例模式仍然成立的编程。

通常，在不考虑序列化和反序列化的情况下，饿汉式单例类定义如下：

针对这个单例类，给出如下的测试程序：

测试程序在控制台的输出结果如下：

测试结果说明，通过单例类两次获得的对象相同；表面上单例模式通过了测试，但是这种测试并不全面。

被测试的单例类所产生的对象在实施序列化后，反序列化时所复原的对象就是一个全新的对象而不是序列化前的那个对象。也就是说，上面给出的单例模式是不完善的，因为它没有考虑到单例对象在序列化前和反序列化后是否是同一个对象的情况。为了验证这一结论，针对序列化的场景再次测试单例类。首先实施单例类创建对象的序列化，测试程序（Singleton1SerializeTest）如下：

在控制台的输出结果是：

然后测试反序列化破坏单例模式的效果；测试程序（Singleton2DeserializeTest）如下：

在控制台的输出结果是：

通过测试结果发现，单例类生成的对象是Singleton@74a14482，序列化后反序列化复原的对象是Singleton@568db2f2，显然这两个对象不是同一个对象。

反序列化为什么能破坏单例模式呢？反序列化的过程是这样的：对象输入流读出序列化文件（singleton.dat）中的类描述符（demo05.serializable.singleton.testfalse.Singleton）并检查JVM环境中是否有相应的class文件已被加载；如果没有加载，使用类加载器加载。然后通过class对象以反射的方式调用单例类的无参构造器创建对象。因此尽管单例类的构造器是私有的，但是对象输出流在反序列化时仍然能够以反射的方式调用它产生对象，这就是反序列化破坏单例模式的原因。

那么如何编程才能保正反序列化下单例模式也能成立呢？答案是：在单例类中添加 private Object readResolve()方法。从形式上看它是私有的，而且需要返回一个对象；从字面上讲，readResolve方法是“读取解析”的意思； “解析”的含义是需要在方法中决定哪一个对象返回给调用者，调用者是对象输入流（ObjectIutputStream）。虽然readResolve方法是私有的，但是对象输入流可以采用反射的方式调用它。通过查询源码发现：在对象输入流实施反序列化后会自动调用readResolve方法，并用返回的对象替换掉反序列化时通过构造器所创建的对象。可见readResolve方法提供的对象才是对象输入流获得的最终对象，因此可以在该方法中提供单例对象从而确保单例模式在反序列化情况下仍然成立。下面是改写后的单例模式，支持反序列化的情况：

采用使用过的测试程序（Singleton2DeserializeTest）程进行测试，在控制台的输出结果如下：

由此可见，在单例模式中，正确理解和添加private Object readResolve()方法，是确保单例模式在反序列化情况下有效的关键。一个完善的单例模式，即需要在多线程环境下能够成功，也需要在序列化和反序列化的实施中过程中仍然成立。