深入Singleton设计模式-java

设计模式之—单例模式(Singleton)-Java实现  一文中实现了简单的单例模式，直接给出一个Singleton的简单实现，因为我相信你已经有这方面的一些基础了。我们姑且把这具版本叫做1.0版。既然单例模式的目标是只能生成一个实例，即整个系统中只能出现一个类的实例。那为何我们不把

private static Singleton instance = new Singleton();   

定义为final呢？如此便有了第二个版本：

public class Singleton {
	private static final Singleton instance = new Singleton();
	private Singleton(){
	}
	public static Singleton getInstance(){
		return instance;
	}
	
}

单例模式有两种模式：饿汉式和懒汉式

上述为饿汉式，下面我们来研究一下饿汉式的存在的问题：前预加载了。但是这种提前加载的方式会在多线程（高并发）环境下造成麻烦。如果private static final Singleton singleton = new Singleton();中的构造方法涉及到异步的网络数据交换如读取服务器配置或者数据库，则此构造过程可能会被操作系统打断而没有完成加载，其他访问singleton实例的线程度脏，而且错误很难查到。

下面来说说懒汉式的Singleton首先还是先上代码：

public class Singleton  
{  
    private static  Singleton singleton = null;  
  
    private Singleton()  
    {  
    }  
    public static Singleton getInstance()  
    {  
        if (singleton== null)  
        {  
            singleton= new Singleton();  
        }  
        return singleton;  
    }  
}  

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

上面的这个程序存在比较严重的问题，因为是全局性的实例，所以，在多线程情况下，所有的全局共享的东西都会变得非常的危险，这个也一样，在多线程情况下，如果多个线程同时调用getInstance()的话，那么，可能会有多个进程同时通过 (singleton== null)的条件检查，于是，多个实例就创建出来，并且很可能造成内存泄露问题。下面就是我们要说的Singleton改进，熟悉多线程的朋友已经知道怎么办了——“我们需要线程互斥或同步”，没错，改进版如下所示：

public class Singleton  
{  
    private static  Singleton singleton = null;  
  
    private Singleton()  
    {  
    }  
    public static Singleton getInstance()  
    {  
        if (singleton== null)  
        {  
            synchronized (Singleton.class) {  
                singleton= new Singleton();  
            }  
        }  
        return singleton;  
    }  
}  

现在看来使用了Java的synchronized方法，没有问题了吧？！但是还是有问题！为什么呢？如果有多个线程同时通过(singleton== null)的条件检查（因为他们并行运行），虽然我们的synchronized方法会帮助我们同步所有的线程，让我们并行线程变成串行的一个一个去new，那不还是一样的吗？同样会出现很多实例。看来，还得把那个判断(singleton== null)条件也同步起来。

public class Singleton  
{  
    private static  Singleton singleton = null;  
  
    private Singleton()  
    {  
    }  
    public static Singleton getInstance()  
    {  
        synchronized (Singleton.class)  
        {  
            if (singleton== null)  
            {  
                singleton= new Singleton();  
            }  
        }  
        return singleton;  
    }  
}  

我们把getInstance()方法也synchronized，这样在多线程下应该没有什么问题了，Singleton在多线程下的确没有问题了，因为我们同步了所有的线程。但是还是有点小问题，我们本来只是想让new这个操作并行就可以了，现在，只要是进入getInstance()的线程都得同步，重点，创建对象的动作只有一次，后面的动作全是读取那个成员变量，这些读取的动作不需要线程同步啊。这样的作法感觉非常不合理，为了一个初始化的创建动作，居然让所有的读操作都同步，严重影响性能！

现在我们在线程同步前还得加一个(singleton== null)的条件判断，如果对象已经创建了，那么就不需要线程的同步了。

public class Singleton  
{  
    private static  Singleton singleton = null;  
  
    private Singleton()  
    {  
    }  
    public static Singleton getInstance()  
    {  
        if (singleton== null)  
        {  
            synchronized (Singleton.class)  
            {  
                if (singleton== null)  
                {  
                    singleton= new Singleton();  
                }  
            }  
        }  
        return singleton;  
    }  
}  

说明：

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

当然这个版本的单例模式，代码看似很丑陋却解决了线程同步的问题。

无论代码写的多么严谨、有多好，其只能在特定的范围内工作，超出这个范围就要出Bug了。

例如：代码运行在多个JVM下照样也会出现多个实例；如果我们的这个Singleton类是一个关于我们程序配置信息的类。我们需要它有序列化的功能，那么，当反序列化的时候，我们将无法控制别人不多次反序列化。不过，我们可以利用一下Serializable接口的readResolve()方法.

import java.io.Serializable;

public class Singleton implements Serializable {
	………………………………
	protected Object readResolve()  
    {  
        return getInstance();  
    }  
}

此外Class Loader类装载器是用来把类(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中的值是不同的。
于是，如果面对着多个Class Loader会怎么样？多个实例同样会被多个Class Loader创建出来，我们怎么可能在我的Singleton类中操作Class Loader啊？是的，你根本不可能。在这种情况下，规范就起到作用了，规定——“保证多个Class Loader不会装载同一个Singleton”。

以上论证了：无论代码写的多么严谨、有多好，其只能在特定的范围内工作，超出这个范围就要出Bug了。