单例模式，几点容易被忽视的问题

Singleton的教学版本 姑且定为1.0 这里值得注意的是构造函数的私有化，解决被继承后的多例问题。

01.// version 1.1 02.public class Singleton 03.{ 04. private static final Singleton singleton = null; 05. 06. private Singleton() 07. { 08. } 09. public static Singleton getInstance() 10. { 11. if (singleton== null) 12. { 13. synchronized (Singleton.class) { 14. singleton= new Singleton(); 15. } 16. } 17. return singleton; 18. } 19.}

其特点是：

1. 私有（private）的构造函数，表明这个类是不可能形成实例了。这主要是怕这个类会有多个实例。
2. 即然这个类是不可能形成实例，那么，我们需要一个静态的方式让其形成实例：getInstance()。注意这个方法是在new自己，因为其可以访问私有的构造函数，所以他是可以保证实例被创建出来的。
3. 在getInstance()中，先做判断是否已形成实例，如果已形成则直接返回，否则创建实例。
4. 所形成的实例保存在自己类中的私有成员中。
5. 我们取实例时，只需要使用Singleton.getInstance()就行了。

然而在实际上，这个单例的运行也是有漏洞的，在多线程的环境下，可以多个线程都在执行到判断语句的时候都通过了空验证，从而进入了后续的初实例化过程。

于是有了以下一个版本1.1：

01.// version 1.1 02.public class Singleton 03.{ 04. private static final Singleton singleton = null; 05. 06. private Singleton() 07. { 08. } 09. public static Singleton getInstance() 10. { 11. if (singleton== null) 12. { 13. synchronized (Singleton.class) { 14. singleton= new Singleton(); 15. } 16. } 17. return singleton; 18. } 19.}

使用了Java的synchronized方法，看起来不错，但是这还是有问题！

为什么呢？前面已经说过，如果有多个线程同时通过(singleton== null)的条件检查（因为他们并行运行），虽然我们的synchronized方法会帮助我们同步所有的线程，让我们并行线程变成串行的一个一个去new，那不还是一样的吗？同样会出现很多实例。嗯，确实如此！看来，还得把那个判断(singleton== null)条件也同步起来。于是，我们的Singleton再次升级成1.2版本，如下所示：

01.// version 1.2 02.public class Singleton 03.{ 04. private static final Singleton singleton = null; 05. 06. private Singleton() 07. { 08. } 09. public static Singleton getInstance() 10. { 11. synchronized (Singleton.class) 12. { 13. if (singleton== null) 14. { 15. singleton= new Singleton(); 16. } 17. } 18. return singleton; 19. } 20.}

然而这样的作法感觉非常极端，为了一个初始化的创建动作，居然让我们达上了所有的读操作，严重影响后续的性能！

做出如下版本的修改1.3：

01.// version 1.3 02.public class Singleton 03.{ 04. private static final Singleton singleton = null; 05. 06. private Singleton() 07. { 08. } 09. public static Singleton getInstance() 10. { 11. if (singleton== null) 12. { 13. synchronized (Singleton.class) 14. { 15. if (singleton== null) 16. { 17. singleton= new Singleton(); 18. } 19. } 20. } 21. return singleton; 22. } 23.}

这个版本有如下特点：

1. 第一个条件是说，如果实例创建了，那就不需要同步了，直接返回就好了。
2. 不然，我们就开始同步线程。
3. 第二个条件是说，如果被同步的线程中，有一个线程创建了对象，那么别的线程就不用再创建了。

可以完全解决多线程问题，同时也解决了一部分的效率问题。

不过，在此基础上依然会有一些问题。当然，这些后续的问题，有待在实际中遇到再推敲。

其一、Class Loader。不知道你对Java的Class Loader熟悉吗？“类装载器”？！C++可没有这个东西啊。这是Java动态性的核心。顾名思义，类装载器是用来把类(class)装载进JVM的。JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-defined class loader)。 在一个JVM中可能存在多个ClassLoader，每个ClassLoader拥有自己的NameSpace。一个ClassLoader只能拥有一个class对象类型的实例，但是不同的ClassLoader可能拥有相同的class对象实例，这时可能产生致命的问题。如ClassLoaderA，装载了类A的类型实例A1，而ClassLoaderB，也装载了类A的对象实例A2。逻辑上讲A1=A2，但是由于A1和A2来自于不同的ClassLoader，它们实际上是完全不同的，如果A中定义了一个静态变量c，则c在不同的ClassLoader中的值是不同的。

于是，如果咱们的Singleton 1.3版本如果面对着多个Class Loader会怎么样？呵呵，多个实例同样会被多个Class Loader创建出来，当然，这个有点牵强，不过他确实存在。难道我们还要整出个1.4版吗？可是，我们怎么可能在我的Singleton类中操作Class Loader啊？是的，你根本不可能。在这种情况下，你能做的只有是——“保证多个Class Loader不会装载同一个Singleton”。

其二、序例化。如果我们的这个Singleton类是一个关于我们程序配置信息的类。我们需要它有序列化的功能，那么，当反序列化的时候，我们将无法控制别人不多次反序列化。不过，我们可以利用一下Serializable接口的readResolve()方法。

其三、多个Java虚拟机。如果我们的程序运行在多个Java的虚拟机中。什么？多个虚拟机？这是一种什么样的情况啊。嗯，这种情况是有点极端，不过还是可能出现，比如EJB或RMI之流的东西。要在这种环境下避免多实例，看来只能通过良好的设计或非技术来解决了。

其四，volatile变量。关于volatile这个关键字所声明的变量可以被看作是一种 “程度较轻的同步synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是synchronized的一部分。当然，如前面所述，我们需要的Singleton只是在创建的时候线程同步，而后面的读取则不需要同步。所以，volatile变量并不能帮助我们即能解决问题，又有好的性能。而且，这种变量只能在JDK 1.5+版后才能使用。

其五、关于继承。是的，继承于Singleton后的子类也有可能造成多实例的问题。不过，因为我们早把Singleton的构造函数声明成了私有的，所以也就杜绝了继承这种事情。

其六，关于代码重用。也话我们的系统中有很多个类需要用到这个模式，如果我们在每一个类都中有这样的代码，那么就显得有点傻了。那么，我们是否可以使用一种方法，把这具模式抽象出去？在C++下这是很容易的，因为有模板和友元，还支持栈上分配内存。