java设计模式——单例模式(Singleton Pattern)

定义：

        单例模式(Singleton Pattern)：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。 单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。

要点：

1. 某个类只能有一个实例；
2. 它必须自行创建这个实例；
3. 它必须自行向整个系统提供这个实例。

单例模式在开发中经常会被用到，写法也多种多样，下面分析几种单例模式的写法：

单线程：

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

上面这种写法是线程不安全的，适用于单线程，因为当有两个线程的时候，假如A线程执行if条件语句时，B线程也有可能执行该语句，所以不能用于多线程。为了能够适用于多线程，可以加一道锁。

多线程：

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

加了同步锁之后就可以在多线程中正常执行了，但是如果单例的方法被多个线程频繁的访问，这样就导致程序执行性能下降，那有没有更好的写法呢？前辈们的智慧是伟大的，他们想出了一个更好的方案——双重检查锁定。通过双重效验来降低同步开销。

public class Singleton {
    private static Singleton instance = null;
    private Singleton(){}
    public static Singleton getInstance(){
        if (null == instance){                     //第一次检查
           synchronized (Singleton.class){       //加同步锁
               if (null == instance){             //第二次检查
                   instance = new Singleton();   //创建对象
                }
            }
        }
        return instance;
    }
}

如上面代码所示，如果第一次检查instance不为null，那么就不需要执行下面的加锁和初始化操作。因此，可以大幅降低synchronized带来的性能开销。 双重检查锁定看起来似乎很完美，但这是一个错误的优化！为什么呢？在线程执行到第4行，代码读取到instance不为null时， instance引用的对象有可能还没有完成初始化。

在第8行创建了一个对象，这行代码可以分解为如下的3行伪代码：

memory = allocate();     // 1.分配对象的内存空间
initinstance(memory);    // 2.初始化对象
instance = memory;       // 3.设置instance指向刚才分配的内存地址

上面3行代码中的2和3之间，可能会被重排序（在一些JIT编译器上，这种重排序是真实发生的，如果不了解重排序，后文JMM会详细解释）。 2和3之间重排序之后的执行时序如下：

memory = allocate();     // 1.分配对象的内存空间
instance = memory;       // 3.设置instance指向刚才分配的内存地址
initinstance(memory);    // 2.初始化对象

如果出现重排序的情况会造成什么后果？假如A线程执行到创建对象的时，然后初始化对象的过程是按照上述顺序初始化，当执行到第二行（instance = memory）时，线程B在第一次检查的时候判断是不为空的，那么接下来如果线程B使用这个对象时就会出现空指针的情况。所以为了避免这个问题，有两种解决方法：

• 不允许重排序的情况。
• 不允许其他线程“看到”这个重排序。

具体解决方案一（静态内部类）：

public class Singleton {
    private Singleton(){}
    private static class SingletonHolder{
        private static Singleton instance = new Singleton();
    }
    public static Singleton getInstance(){
        return SingletonHolder.instance;     //这里才会导致 SingletonHolder类被初始化
    }
}

这个方案的本质是允许前面伪代码谈到的2和3重排序，但不允许其他线程“看到”这个重排序。在Singleton 示例代码中， 首次执行getInstance()方法的线程将导致InstanceHolder类被初始化。由于Java语言是多线程的， 多个线程可能在同一时间尝试去初始化同一个类或接口（比如这里多个线程可能会在同一时刻调用getInstance()方法来初始化IInstanceHolder类）。 Java语言规定，对于每一个类和接口C，都有一个唯一的初始化锁LC与之对应。从C到LC的映射，由JVM的具体实现去自由实现。 JVM在类初始化期间会获取这个初始化锁，并且每个线程至少获取一次锁来确保这个类已经被初始化过了。

方案二（volatitle）：

public class Singleton {
    private volatile static Singleton instance = null;
    private Singleton(){}
    public static Singleton getInstance(){
        if (null == instance){                     //第一次检查
           synchronized (Singleton.class){       //加同步锁
               if (null == instance){             //第二次检查
                   instance = new Singleton();   //创建对象
                }
            }
        }
        return instance;
    }
}

当声明对象的引用为volatile后，前面伪代码谈到的2和3之间的重排序，在多线程环境中将会被禁止。

在单例模式的实现过程中，需要注意如下三点：

• 单例类的构造函数为私有；
• 提供一个自身的静态私有成员变量；
• 提供一个公有的静态工厂方法。

单例模式优点：

• 提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它，并为设计及开发团队提供了共享的概念。
• 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。
• 允许可变数目的实例。我们可以基于单例模式进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例。

单例模式缺点：

• 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
• 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。
• 滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术， 因此，如果实例化的对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致对象状态的丢失。

单例模式适用环境：

• 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器，或者需要考虑资源消耗太大而只允许创建一个对象。
• 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
• 在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来，如果一个类可以有几个实例共存，就需要对单例模式进行改进，使之成为多例模式