单例模式

转自：https://www.cnblogs.com/xiaoxi/p/7799456.html

单例模式作为一种目标明确、结构简单、理解容易的设计模式，在软件开发中使用频率相当高，在很多应用软件和框架中都得以广泛应用。

1.主要优点

单例模式的主要优点如下：

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

2.主要缺点

单例模式的主要缺点如下：

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

3.适用场景

在以下情况下可以考虑使用单例模式：

• 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。
• 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。

---

      所谓单例，指的就是单实例，有且仅有一个类实例，这个单例不应该由人来控制，而应该由代码来限制，强制单例。

　  单例有其独有的使用场景，一般是对于那些业务逻辑上限定不能多例只能单例的情况，例如：类似于计数器之类的存在，一般都需要使用一个实例来进行记录，若多例计数则会不准确。

　  其实单例就是那些很明显的使用场合，没有之前学习的那些模式所使用的复杂场景，只要你需要使用单例，那你就使用单例，简单易理解。

      所以我认为有关单例模式的重点不在于场景，而在于如何使用。

1、常见的单例模式有两种创建方式：所谓饿懒汉式与饿汉式

（1）懒汉式

　  何为懒？顾名思义，就是不做事，这里也是同义，懒汉式就是不在系统加载时就创建类的单例，而是在第一次使用实例的时候再创建。

详见下方代码示例：

public class LHanDanli {
    //定义一个私有类变量来存放单例，私有的目的是指外部无法直接获取这个变量，而要使用提供的公共方法来获取
    private static LHanDanli dl = null;
    //定义私有构造器，表示只在类内部使用，亦指单例的实例只能在单例类内部创建
    private LHanDanli(){}
    //定义一个公共的公开的方法来返回该类的实例，由于是懒汉式，需要在第一次使用时生成实例，所以为了线程安全，使用synchronized关键字来确保只会生成单例
    public static synchronized LHanDanli getInstance(){
        if(dl == null){
            dl = new LHanDanli();
        }
        return dl;
    }
}

（2）饿汉式

     又何为饿？饿者，饥不择食；但凡有食，必急食之。此处同义：在加载类的时候就会创建类的单例，并保存在类中。

详见下方代码示例：

public class EHanDanli {
    //此处定义类变量实例并直接实例化，在类加载的时候就完成了实例化并保存在类中
    private static EHanDanli dl = new EHanDanli();
    //定义无参构造器，用于单例实例
    private EHanDanli(){}
    //定义公开方法，返回已创建的单例
    public static EHanDanli getInstance(){
        return dl;
    }
}

2、双重加锁机制

     何为双重加锁机制？

     在懒汉式实现单例模式的代码中，有使用synchronized关键字来同步获取实例，保证单例的唯一性，但是上面的代码在每一次执行时都要进行同步和判断，无疑会拖慢速度，使用双重加锁机制正好可以解决这个问题：

public class SLHanDanli {
    private static volatile SLHanDanli dl = null;
    private SLHanDanli(){}
    public static SLHanDanli getInstance(){
        if(dl == null){
            synchronized (SLHanDanli.class) {
                if(dl == null){
                    dl = new SLHanDanli();
                }
            }
        }
        return dl;
    }
}

看了上面的代码，有没有感觉很无语，双重加锁难道不是需要两个synchronized进行加锁的吗？

    其实不然，这里的双重指的的双重判断，而加锁单指那个synchronized，为什么要进行双重判断，其实很简单，第一重判断，如果单例已经存在，那么就不再需要进行同步操作，而是直接返回这个实例，如果没有创建，才会进入同步块，同步块的目的与之前相同，目的是为了防止有两个调用同时进行时，导致生成多个实例，有了同步块，每次只能有一个线程调用能访问同步块内容，当第一个抢到锁的调用获取了实例之后，这个实例就会被创建，之后的所有调用都不会进入同步块，直接在第一重判断就返回了单例。至于第二个判断，个人感觉有点查遗补漏的意味在内（期待高人高见）。

    不论如何，使用了双重加锁机制后，程序的执行速度有了显著提升，不必每次都同步加锁。

    其实我最在意的是volatile的使用，volatile关键字的含义是：被其所修饰的变量的值不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存来实现，从而确保多个线程能正确的处理该变量。该关键字可能会屏蔽掉虚拟机中的一些代码优化，所以其运行效率可能不是很高，所以，一般情况下，并不建议使用双重加锁机制，酌情使用才是正理！

3、类级内部类方式

    饿汉式会占用较多的空间，因为其在类加载时就会完成实例化，而懒汉式又存在执行速率慢的情况，双重加锁机制呢？又有执行效率差的毛病，有没有一种完美的方式可以规避这些毛病呢？

    貌似有的，就是使用类级内部类结合多线程默认同步锁，同时实现延迟加载和线程安全。

public class ClassInnerClassDanli {
    public static class DanliHolder{
        private static ClassInnerClassDanli dl = new ClassInnerClassDanli();
    }
    private ClassInnerClassDanli(){}
    public static ClassInnerClassDanli getInstance(){
        return DanliHolder.dl;
    }
}

如上代码，所谓类级内部类，就是静态内部类，这种内部类与其外部类之间并没有从属关系，加载外部类的时候，并不会同时加载其静态内部类，只有在发生调用的时候才会进行加载，加载的时候就会创建单例实例并返回，有效实现了懒加载（延迟加载），至于同步问题，我们采用和饿汉式同样的静态初始化器的方式，借助JVM来实现线程安全。

    其实使用静态初始化器的方式会在类加载时创建类的实例，但是我们将实例的创建显式放置在静态内部类中，它会导致在外部类加载时不进行实例创建，这样就能实现我们的双重目的：延迟加载和线程安全。

4、使用

    在Spring中创建的Bean实例默认都是单例模式存在的。