设计模式学习 - 单例模式-优快云博客

本文链接：https://blog.youkuaiyun.com/zhonghua_csdn/article/details/102805375

单例模式（Singleton Pattern）

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

为什么使用单例模式？

避免一个全局使用的类频繁地创建与销毁，控制实例数目，节省系统资源。

image.png

使用场景

要求生产唯一序列号。
创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。

代码示例

饿汉式单例

namespace SingletonPattern
{
    // 饿汉式单例
    public class SingletonPatternDemo01
    {
        // 无论用不用这个类，这个空间都会被开辟。 
        // 当代码一运行，就会被初始化到内存中。
        //private byte[] data1 = new byte[1024 * 1024 * 1024/4];
        //private byte[] data2 = new byte[1024 * 1024 * 1024/4];
        //private byte[] data3 = new byte[1024 * 1024 * 1024/4];
        //private byte[] data4 = new byte[1024 * 1024 * 1024/4];



        // 私有化构造器
        private SingletonPatternDemo01()
        { 
        
        }

        // 在类初始化的时候，立即加载该对象
        private static SingletonPatternDemo01 Instance = new SingletonPatternDemo01();

        // 提供获取该对象的方法
        public static SingletonPatternDemo01 GetInstance()
        {
            return Instance; 
        }

    }
}

优点

在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例。
避免对资源的多重占用（比如写文件操作）。

缺点

没有接口，不能继承。
与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
单例的缺点就是不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。

以下为资料收集，待整理：

单例模式是设计模式中最简单的形式之一。这一模式的目的是使得类的一个对象成为系统中的唯一实例。要实现这一点，可以从客户端对其进行实例化开始。因此需要用一种只允许生成对象类的唯一实例的机制，“阻止”所有想要生成对象的访问。使用工厂方法来限制实例化过程。这个方法应该是静态方法（类方法），因为让类的实例去生成另一个唯一实例毫无意义。^[1]

实现方式

通常单例模式在Java语言中，有两种构建方式：

懒汉式—线程不安全：最基础的实现方式，线程上下文单例，不需要共享给所有线程，也不需要加synchronize之类的锁，以提高性能。
懒汉式—线程安全：加上synchronize之类保证线程安全的基础上的懒汉模式，相对性能很低，大部分时间并不需要同步
饿汉方式。指全局的单例实例在类装载时构建。^[2]
双检锁式。在懒汉式基础上利用synchronize关键字和volatile关键字确保第一次创建时没有线程间竞争而产生多个实例，仅第一次创建时同步，性能相对较高
登记式。作为创建类的全局属性存在，创建类被装载时创建
枚举。java中枚举类本身也是一种单例模式

动机

对于系统中的某些类来说，只有一个实例很重要，例如，一个系统中可以存在多个打印任务，但是只能有一个正在工作的任务；一个系统只能有一个窗口管理器或文件系统；一个系统只能有一个计时工具或ID(序号)生成器。如在Windows中就只能打开一个任务管理器。如果不使用机制对窗口对象进行唯一化，将弹出多个窗口，如果这些窗口显示的内容完全一致，则是重复对象，浪费内存资源；如果这些窗口显示的内容不一致，则意味着在某一瞬间系统有多个状态，与实际不符，也会给用户带来误解，不知道哪一个才是真实的状态。因此有时确保系统中某个对象的唯一性即一个类只能有一个实例非常重要。^[2]

如何保证一个类只有一个实例并且这个实例易于被访问呢？定义一个全局变量可以确保对象随时都可以被访问，但不能防止我们实例化多个对象。一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。^[2]

要点

[编辑](javascript:;)

显然单例模式的要点有三个；一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。

从具体实现角度来说，就是以下三点：一是单例模式的类只提供私有的构造函数，二是类定义中含有一个该类的静态私有对象，三是该类提供了一个静态的公有的函数用于创建或获取它本身的静态私有对象。

在下面的对象图中，有一个"单例对象"，而"客户甲"、"客户乙" 和"客户丙"是单例对象的三个客户对象。可以看到，所有的客户对象共享一个单例对象。而且从单例对象到自身的连接线可以看出，单例对象持有对自己的引用。

一些资源管理器常常设计成单例模式。

在计算机系统中，需要管理的资源包括软件外部资源，譬如每台计算机可以有若干个打印机，但只能有一个Printer Spooler，以避免两个打印作业同时输出到打印机中。每台计算机可以有若干传真卡，但是只应该有一个软件负责管理传真卡，以避免出现两份传真作业同时传到传真卡中的情况。每台计算机可以有若干通信端口，系统应当集中管理这些通信端口，以避免一个通信端口同时被两个请求同时调用。

需要管理的资源包括软件内部资源，譬如，大多数的软件都有一个（甚至多个）属性（properties）文件存放系统配置。这样的系统应当由一个对象来管理一个属性文件。

需要管理的软件内部资源也包括譬如负责记录网站来访人数的部件，记录软件系统内部事件、出错信息的部件，或是对系统的表现进行检查的部件等。这些部件都必须集中管理，不可整出多头。

这些资源管理器构件必须只有一个实例，这是其一；它们必须自行初始化，这是其二；允许整个系统访问自己这是其三。因此，它们都满足单例模式的条件，是单例模式的应用。^[1]

优缺点

[编辑](javascript:;)

优点

一、实例控制

单例模式会阻止其他对象实例化其自己的单例对象的副本，从而确保所有对象都访问唯一实例。

二、灵活性

因为类控制了实例化过程，所以类可以灵活更改实例化过程。

缺点

一、开销

虽然数量很少，但如果每次对象请求引用时都要检查是否存在类的实例，将仍然需要一些开销。可以通过使用静态初始化解决此问题。

二、可能的开发混淆

使用单例对象（尤其在类库中定义的对象）时，开发人员必须记住自己不能使用new关键字实例化对象。因为可能无法访问库源代码，因此应用程序开发人员可能会意外发现自己无法直接实例化此类。

三、对象生存期

不能解决删除单个对象的问题。在提供内存管理的语言中（例如基于.NET Framework的语言），只有单例类能够导致实例被取消分配，因为它包含对该实例的私有引用。在某些语言中（如 C++），其他类可以删除对象实例，但这样会导致单例类中出现悬浮引用。^[2]

我们在编程中最常用的模式就是单例模式了，然而单例模式都用在什么场合？为什么不用静态方法而要用单例模式呢？要搞清这些问题，需要从静态方法和非静态方法的区别和联系说起。
一、静态方法常驻内存，非静态方法只有使用的时候才分配内存？
一般都认为是这样，并且怕静态方法占用过多内存而建议使用非静态方法，其实这个理解是错误的。
为什么会这样，先从内存分配开始说起：
托管堆的定义：对于32位的应用程序来说，应用程序完成进程初始化后，CLR将在进程的可用地址空间分配一块保留的地址空间，它是进程（每个进程可使用4GB）中可用地址空间上的一块内存区域，但并不对应任何物理内存，这块地址空间即是托管堆。
托管堆有分为多个区域，其中最重要的是垃圾回收堆（GC Heap）和加载堆（Loader Heap），GC Heap用于存储对象实例，受GC管理；Loader Heap又分为High-Frequency Heap、Low-Frequency Heap和Stub Heap，不同的堆上又存储不同的信息。Loader Heap最重要的信息就是元数据相关的信息，也就是Type对象，每个Type在Loader Heap上体现为一个Method Table（方法表），而Method Table中则记录了存储的元数据信息，例如基类型、静态字段、实现的接口、所有的方法等等。Loader Heap不受GC控制，其生命周期为从创建到AppDomain卸载。（摘自《你必须知道的.Net》）
由此我们就明白了，静态方法和非静态方法，在内存里其实都放在Method Table里了，在一个类第一次被加载的时候，它会在Loader Heap里把静态方法，非静态方法都写入Method Table中，而且Loader Heap不受GC控制，所以一旦加载，GC就不会回收，直到AppDomain卸载
由此我们也明白了，静态方法和非静态方法，他们都是在第一次加载后就常驻内存，所以方法本身在内存里，没有什么区别，所以也就不存在”静态方法常驻内存，非静态方法只有使用的时候才分配内存“这个结论了。
二、静态方法和非静态方法的区别？
在内存中的区别是，非静态方法在创建实例对象时，因为属性的值对于每个对象都各不相同，因此在new一个实例时，会把这个实例属性在GC Heap里拷贝一份，同时这个new出来的对象放在堆栈上，堆栈指针指向了刚才拷贝的那一份实例的内存地址上。而静态方法则不需要，因为静态方法里面的静态字段，就是保存在Method Table里了，只有一份。
因此静态方法和非静态方法，在调用速度上，静态方法速度一定会快点，因为非静态方法需要实例化，分配内存，但静态方法不用，但是这种速度上差异可以忽略不计。
三、为什么要有非静态方法？
早期的结构化编程，几乎所有的方法都是“静态方法”，引入实例化方法概念是面向对象概念出现以后的事情了，区分静态方法和实例化方法不能单单从性能上去理解，创建c++,java,c#这样面向对象语言的大师引入实例化方法一定不是要解决什么性能、内存的问题，而是为了让开发更加模式化、面向对象化。这样说的话，静态方法和实例化方式的区分是为了解决模式的问题。
接下来继续思考，如果我们全部用静态方法，不用非静态方法，不是一样能实现功能吗？是的，没错，但是你的代码是基于对象，而不是面向对象的，因为面向对象的继承和多态，都是非静态方法。
第二个原因是为什么不建议都用静态方法，我们如果多线程的情况下，如果静态方法使用了一个静态字段，这个静态字段可以会被多个线程修改，因此说如果在静态方法里使用了静态变量，这就会有线程安全问题，当然了，就算不是多线程，因为静态字段只有一份，同样会有被其他地方修改的问题。
从这三点我们得出的结论如下：
一、什么时候用静态方法，什么时候使用非静态方法？
既然静态方法和实例化方式的区分是为了解决模式的问题，如果我们考虑不需要继承和多态的时候，就可以使用静态方法，但就算不考虑继承和多态，就一概使用静态方法也不是好的编程思想。

从另一个角度考虑，如果一个方法和他所在类的实例对象无关，那么它就应该是静态的，否则就应该是非静态。因此像工具类，一般都是静态的。

二、为什么使用单例模式而不用静态方法？
从面相对象的角度讲：
虽然都能实现目的，但是他们一个是基于对象，一个是面向对象的，就像我们不面相对象也能解决问题一样，面相对象的代码提供一个更好的编程思想。

如果一个方法和他所在类的实例对象无关，那么它就应该是静态的，反之他就应该是非静态的。如果我们确实应该使用非静态的方法，但是在创建类时又确实只需要维护一份实例时，就需要用单例模式了。

比如说我们在系统运行时候，就需要加载一些配置和属性，这些配置和属性是一定存在了，又是公共的，同时需要在整个生命周期中都存在，所以只需要一份就行，这个时候如果需要我再需要的时候new一个，再给他分配值，显然是浪费内存并且再赋值没什么意义，所以这个时候我们就需要单例模式或静态方法去维持一份且仅这一份拷贝，但此时这些配置和属性又是通过面向对象的编码方式得到的，我们就应该使用单例模式，或者不是面向对象的，但他本身的属性应该是面对对象的，我们使用静态方法虽然能同样解决问题，但是最好的解决方案也应该是使用单例模式。
从功能上讲：单例模式可以控制单例数量；可以进行有意义的派生；对实例的创建有更自由的控制;

三、其他：
数据库连接能不能做SingleTon？
如果是简单地把一个connection对象封存在单例对象中，这样是错误的，因此连接池里有多个链接可以用，如果使用SingleTon，那在WEB访问时，就只能用一个数据库链接，那不是死的很惨？
但是链接池可以使用单例模式，初始化的时候创建譬如100个connection对象，然后再需要的时候提供一个，用过之后返回到pool中，我们用单例模式，是保证连接池有且只有一个。
再举个例子，比如DAL层写好一个调用数据库表的类，在BLL层应用此类时，如果每次都new创建的话需要频繁的创建和回收，而DAL层这个类里又没有和对象相关的值变量，所以不需要每次都new一个，这时候就可以用单例模式来创建这个DAL实例。