Singleton设计模式

单实例Singleton设计模式多是被讨论和使用的最普遍的一个设计模式了，这可能也是面试中问得最多的一个设计模式了。这个设计模式主要目的是想在整个系统中只能出现一个类的实例。这样作固然是有必然的，好比你的软件的全局配置信息，或者是一个Factory，或是一个主控类，等等。你但愿这个类在整个系统中只能出现一个实例。固然，做为一个技术负责人的你，你固然有权利经过使用非技术的手段来达到你的目的。好比：你在团队内部明文规定，“XX类只能有一个全局实例，若是某人使用两次以上，那么该人将被处于2000元的罚款！”（呵呵），你固然有权这么作。可是若是你的设计的是东西是一个类库，或是一个须要提供给用户使用的API，恐怕你的这项规定将会失效。由于，你无权要求别人会那么作。因此，这就是为何，咱们但愿经过使用技术的手段来达成这样一个目的的缘由。

本文会带着你深刻整个Singleton的世界，固然，我会放弃使用C++语言而改用Java语言，由于使用Java这个语言可能更容易让我说明一些事情。

Singleton的教学版本

这里，我将直接给出一个Singleton的简单实现，由于我相信你已经有这方面的一些基础了。咱们姑且把这个版本叫作1.0版 1 2 3 4 5 6 7 8 9 10 11

// version 1.0 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()就好了。
复制代码

固然，若是你以为知道了上面这些事情后就学成了，那得给你当头棒喝一下了，事情远远没有那么简单。 Singleton的实际版本

上面的这个程序存在比较严重的问题，由于是全局性的实例，因此，在多线程状况下，全部的全局共享的东西都会变得很是的危险，这个也同样，在多线程状况下，若是多个线程同时调用getInstance()的话，那么，可能会有多个进程同时经过 (singleton== null)的条件检查，因而，多个实例就建立出来，而且极可能形成内存泄露问题。嗯，熟悉多线程的你必定会说——“咱们须要线程互斥或同步”，没错，咱们须要这个事情，因而咱们的Singleton升级成1.1版，以下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14

// version 1.1 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)条件也同步起来。因而，咱们的Singleton再次升级成1.2版本，以下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14

// version 1.2 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; } }

不错不错，看似很不错了。在多线程下应该没有什么问题了，不是吗？的确是这样的，1.2版的Singleton在多线程下的确没有问题了，由于咱们同步了全部的线程。只不过嘛……，什么？！还不行？！是的，仍是有点小问题，咱们原本只是想让new这个操做并行就能够了，如今，只要是进入getInstance()的线程都得同步啊，注意，建立对象的动做只有一次，后面的动做全是读取那个成员变量，这些读取的动做不须要线程同步啊。这样的做法感受很是极端啊，为了一个初始化的建立动做，竟然让咱们达上了全部的读操做，严重影响后续的性能啊！

还得改！嗯，看来，在线程同步前还得加一个(singleton== null)的条件判断，若是对象已经建立了，那么就不须要线程的同步了。OK，下面是1.3版的Singleton。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

// version 1.3 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; } }

感受代码开始变得有点罗嗦和复杂了，不过，这多是最不错的一个版本了，这个版本又叫“双重检查”Double-Check。下面是说明：

第一个条件是说，若是实例建立了，那就不须要同步了，直接返回就行了。
否则，咱们就开始同步线程。
第二个条件是说，若是被同步的线程中，有一个线程建立了对象，那么别的线程就不用再建立了。
复制代码

至关不错啊，干得很是漂亮！请你们为咱们的1.3版起立鼓掌！

可是，若是你认为这个版本大攻告成，你就错了。

主要在于singleton = new Singleton()这句，这并不是是一个原子操做，事实上在 JVM 中这句话大概作了下面 3 件事情。

给 singleton 分配内存
调用 Singleton 的构造函数来初始化成员变量，造成实例
将singleton对象指向分配的内存空间（执行完这步 singleton才是非 null 了）
复制代码

可是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序多是 1-2-3 也多是 1-3-2。若是是后者，则在 3 执行完毕、2 未执行以前，被线程二抢占了，这时 instance 已是非 null 了（但却没有初始化），因此线程二会直接返回 instance，而后使用，而后瓜熟蒂落地报错。

对此，咱们只须要把singleton声明成 volatile 就能够了。下面是1.4版：

// version 1.4
public class Singleton
{
    private volatile static Singleton singleton = null;
    private Singleton()  {    }
    public static Singleton getInstance()   {
        if (singleton== null)  {
            synchronized (Singleton.class) {
                if (singleton== null)  {
                    singleton= new Singleton();
                }
            }
        }
        return singleton;
    }
}
复制代码

使用 volatile 有两个功用：

1）这个变量不会在多个线程中存在复本，直接从内存读取。

2）这个关键字会禁止指令重排序优化。也就是说，在 volatile 变量的赋值操做后面会有一个内存屏障（生成的汇编代码上），读操做不会被重排序到内存屏障以前。

可是，这个事情仅在Java 1.5版后有用，1.5版以前用这个变量也有问题，由于老版本的Java的内存模型是有缺陷的。 Singleton 的简化版本

上面的玩法实在是太复杂了，一点也不优雅，下面是一种更为优雅的方式：

这种方法很是简单，由于单例的实例被声明成 static 和 final 变量了，在第一次加载类到内存中时就会初始化，因此建立实例自己是线程安全的。

// version 1.5
public class Singleton
{
    private volatile static Singleton singleton = new Singleton();
    private Singleton()  {    }
    public static Singleton getInstance()   {
        return singleton;
    }
}
复制代码

可是，这种玩法的最大问题是——当这个类被加载的时候，new Singleton() 这句话就会被执行，就算是getInstance()没有被调用，类也被初始化了。

因而，这个可能会与咱们想要的行为不同，好比，个人类的构造函数中，有一些事可能须要依赖于别的类干的一些事（好比某个配置文件，或是某个被其它类建立的资源），咱们但愿他能在我第一次getInstance()时才被真正的建立。这样，咱们能够控制真正的类建立的时刻，而不是把类的建立委托给了类装载器。

好吧，咱们还得绕一下：

下面的这个1.6版是老版《Effective Java》中推荐的方式。

// version 1.6
public class Singleton {
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
    private Singleton (){}
    public static final Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}
复制代码

上面这种方式，仍然使用JVM自己机制保证了线程安全问题；因为 SingletonHolder 是私有的，除了 getInstance() 以外没有办法访问它，所以它只有在getInstance()被调用时才会真正建立；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本。 Singleton 优雅版本

public enum Singleton{
   INSTANCE;
}
复制代码

竟然用枚举！！看上去好牛逼，经过EasySingleton.INSTANCE来访问，这比调用getInstance()方法简单多了。

默认枚举实例的建立是线程安全的，因此不须要担忧线程安全的问题。可是在枚举中的其余任何方法的线程安全由程序员本身负责。还有防止上面的经过反射机制调用私用构造器。

这个版本基本上消除了绝大多数的问题。代码也很是简单，实在没法不用。这也是新版的《Effective Java》中推荐的模式。 Singleton的其它问题

怎么？还有问题？！固然还有，请记住下面这条规则——“不管你的代码写得有多好，其只能在特定的范围内工做，超出这个范围就要出Bug了”，这是“陈式第必定理”，呵呵。你能想想还有什么状况会让这个咱们上面的代码出问题吗？

在C++下，我不是很好举例，可是在Java的环境下，嘿嘿，仍是让咱们来看看下面的一些反例和一些别的事情的讨论（固然，有些反例可能属于钻牛角尖，可能有点学院派，不过也不排除其实际可能性，就算是提个醒吧）：

其1、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”。

其2、序例化。若是咱们的这个Singleton类是一个关于咱们程序配置信息的类。咱们须要它有序列化的功能，那么，当反序列化的时候，咱们将没法控制别人很少次反序列化。不过，咱们能够利用一下Serializable接口的readResolve()方法，好比：

public class Singleton implements Serializable
{
    ......
    ......
    protected Object readResolve()
    {
        return getInstance();
    }
}
复制代码

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

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

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

其六，关于代码重用。也话咱们的系统中有不少个类须要用到这个模式，若是咱们在每个类都中有这样的代码，那么就显得有点傻了。那么，咱们是否可使用一种方法，把这具模式抽象出去？在C++下这是很容易的，由于有模板和友元，还支持栈上分配内存，因此比较容易一些（程序以下所示），Java下可能比较复杂一些，聪明的你知道怎么作吗？

template class Singleton
{
    public:
        static T& Instance()
        {
            static T theSingleInstance; //假设T有一个protected默认构造函数
            return theSingleInstance;
        }
};
 
class OnlyOne : public Singleton
{
    friend class Singleton;
    int example_data;
 
    public:
        int GetExampleData() const {return example_data;}
    protected:
        OnlyOne(): example_data(42) {}   // 默认构造函数
        OnlyOne(OnlyOne&) {}
};
 
int main( )
{
    cout << OnlyOne::Instance().GetExampleData() << endl;
    return 0;
}
复制代码

文章转载自：coolshell.cn/articles/26…