单例模式应用场景_【简易设计模式04】单例模式

总第56篇

在上篇中，我们对整个系统的设计应遵循的六大设计原则进行了系统性的梳理和讲解。在开发过程中，我们应尽量按照这些设计原则去做，当然也不能生搬硬套，要适当权衡，根据自己的项目情况、项目场景去考量。从本篇开始，将通俗易懂地介绍23种设计模式。

本篇将详细梳理单例模式。

1.单例模式的概念

单例模式（Singleton Pattern）是一个比较简单的设计模式，它确保某一个类只有一个实例，并且自行实例化后向整个系统提供一个访问它的全局方法。

单例模式的一般通用代码如下：

public class Singleton {private static final Singleton singleton = new Singleton();private Singleton(){}   //私有化构造函数//获取实例对象public static Singleton getInstance(){return singleton;}//其他方法，尽量是static类型的public static void doSomething(){}
}

在Java和C++中，单例模式的另一种通用的写法如下：

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

但是，这种通用写法要考虑到线程同步问题。上面的代码在系统高并发时，系统内还是可能存在多个实例，破坏了最初的预期，比如，线程1执行到singleton = new Singleton()而还没有获得对象时（对象初始化需要时间），线程2刚好执行到singleton == null，此时内存中就会出现两个对象。因此，如果不想考虑线程同步问题，可以简单地使用一般通用模式。

2.单例模式的优缺点及使用场景

单例模式的优点可以归结为以下几个方面：

可以大大减少内存开销。特别是对象需要频繁创建、销毁并且无法有效优化时，这种优势更加明显；
可避免对资源的多重占用。比如一个写文件动作，因为只有一个实例存在内存中，可有效避免对同一个资源文件同时写操作；
可方便设置系统全局访问点。这种方式可以大大优化共享资源的访问；

单例模式的缺点可以归结为以下几个方面：

单例模式一般没有接口，扩展比较困难。要扩展只能修改原有的代码；
单例模式不利于测试。在并行开发环境中，若单例模式没有完成，是不能进行测试的；
单例模式与单一职责原则有冲突。单例模式将“要不要单例”与业务逻辑融合在一个类中；

在一个系统中，若要求一个类有且仅有一个对象，则可以采用单例模式。具体的使用场景如下：

要求生成唯一序列号的环境；
在整个项目中需要一个共享访问点或共享数据时；
创建或销毁一个对象消耗的资源过多时；
需要定义大量的静态常量和静态方法时；

3.单例模式的扩展形式

若一个类可以产生多个对象，对象的数量不受限制，这是非常容易实现的，直接new出多个对象就可以了。而有时，对于某个类，我们需要两三个或固定个数的对象实例，这时实现起来就略微有些复杂了。

这种产生固定数量对象的模式称作有上限的多例模式，它是单例模式的一种扩展。对于这种模式，我们在设计时，在类中定义一个private变量，存储实例的个数，并且在构造函数中将这些实例全部创建出来，方便系统后面使用。

单例模式是23个设计模式中比较简单的模式，应用也非常广泛，下图示例了单例模式的概括图。

本文到此结束！下篇继续！

如果对你有帮助，请随手点赞或赞赏！关注本专栏，更多干货与你分享。

=======================================================

欢迎【关注、私信 @武三郎】。我们一起交流一起进步。