【设计模式】单例模式、“多例模式”的实现以及对单例的一些思考

文章目录

1.概述
2.单例模式实现代码
- 2.1.饿汉式单例
- 2.2.懒汉式单例
- 2.3.双检锁单例
- 2.4.静态内部类单例
- 2.5.枚举单例
3.对单例的一些思考
- 3.1.是否需要严格的禁止单例被破坏？
- 3.2.懒汉式真的比饿汉式更佳吗？
- 3.3.单例存在的问题
4.其他作用范围的单例模式
- 4.1.线程内的单例
- 4.2.进程间的单例
5.“多例模式”
6.总结

1.概述

单例模式是设计模式中最简单的一种，对于很多人来说，单例模式也是其接触的第一种设计模式，当然，我也不例外。这种设计模式在学习、面试、工作的过程中广泛传播，相信不少人在面试时遇到过这样的问题：“说说你最熟悉的集中设计模式”，第一个脱口而出的就是单例模式。

所谓的单例模式，就是在一定的作用范围内保证只有一个实例，这种模式，简单，但是想要使用好它，还需要学习一下它延伸出来的其他知识点，本篇博文就对单例模式做一下简单的整理，主要会包含以下几部分内容：

单例模式的代码如何编写？
是否需要严格的禁止单例被破坏？
饿汉式和懒汉式应该如何选择？
单例模式存在什么问题？
线程内单例和进程间单例如何实现？
什么叫做“多例模式”？

2.单例模式实现代码

单例模式的实现代码很多，下面会例举一些常见的方式。

在Java中，单例模式的作用范围一般情况下指的是当前的Java进程，也就是进程内的对象保证唯一（当然还有线程内、进程之间的单例，下面会提到），所以我们需要保证实例只会被初始化一次，如何保证呢？

2.1.饿汉式单例

一个简单的做法，就是私有化构造方法，也就是不让外部的客户端对象来调用new方法，创建新的实例，而是在项目启动时，由单例类自行初始化，这就是饿汉式单例

/*** 饿汉式单例*/
public class HungrySingleton {private static final HungrySingleton HUNGRY_SINGLETON = new HungrySingleton();private HungrySingleton() {}public static HungrySingleton getInstance() {return HUNGRY_SINGLETON;}
}

2.2.懒汉式单例

如果不想再项目启动时初始化，而是在使用的时候再初始化对象，可以将对象的创建放到getInstance方法中，这种方式叫做懒汉式单例。这种方式在多线程的情况下会有线程安全问题，需要在创建对象时加锁。

/*** 懒汉式单例*/
public class LazySingleton {private static volatile LazySingleton lazySingleton;private LazySingleton() {}public static synchronized LazySingleton getInstance() {if (lazySingleton == null) {lazySingleton = new LazySingleton();}return lazySingleton;}
}

2.3.双检锁单例

在方法加的是类锁，一次只有一个线程可以获取到单例对象，为了提高获取对象的效率，取消在方法上的类锁，转而只给创建对象的那一行代码加锁。但是在并发的情况下，多个线程同时进入getInstance方法，都可以通过lazySingleton == null的判断，并在加锁那一行排队，每个线程都会创建一个新的对象，所以，我们需要在锁里面再判断一次对象是否创建。
这种在加锁的代码前后都进行一次相同判断的做法，我们叫做双重检查锁，简称：双检锁。

/*** 双检锁单例*/
public class LazySingleton {private static volatile LazySingleton lazySingleton;private LazySingleton() {}public static LazySingleton getInstance() {if (lazySingleton == null) {synchronized (LazySingleton.class) {if (lazySingleton == null) {lazySingleton = new LazySingleton();}}}return lazySingleton;}
}

2.4.静态内部类单例

上面的懒汉式是为了保证懒加载的同时，又不能有线程安全问题，我们采用了加锁的方式，那么不加锁行不行呢？
当然是可以的，我们采用静态内部类在受访问时才会初始化的特性，来实现懒加载。

/*** 静态内部类单例*/
public class StaticClassSingleton {private StaticClassSingleton() {}public static StaticClassSingleton getInstance() {return InnerStaticClassSingleton.STATIC_CLASS_SINGLETON;}private static class InnerStaticClassSingleton {private static final StaticClassSingleton STATIC_CLASS_SINGLETON = new StaticClassSingleton();}
}

2.5.枚举单例

Java中的枚举是天然的单例模式，这种方式实现最简单，而且不会有线程安全问题，也能避免通过反射或者反序列化创建新的对象。
下面代码中的INSTANCE就是单例对象了。

/*** 枚举单例*/
public enum EnumSingleton {INSTANCE;
}

3.对单例的一些思考

3.1.是否需要严格的禁止单例被破坏？

在上面的代码例子中，我们采用的方式是私有化构造方法方法来避免外部对象new出新的单例对象，但这种方式并不能完全避免创建出新的对象。其实上面的枚举单例中已经提到了，可以通过反射、反序列化等方式，创建出新的对象。

在考虑如何避免通过反射、反序列化创建对象，可以先思考一下，有没有必要去避免？

还是回到最初那个点，我们用了这么多方式来实现单例模式，最终的目的就是为了在进程内的作用范围内只有一个实例。而在代码的开发过程中，我们做好规范和约束，以人为的方式来控制对象的创建数量，哪怕没有私有化构造方法方法也能保证单例。而我们私有化构造方法，更多的是给开发者做出一个提示，这个类是个单例类，并且防止一定的误操作。
可以想象一下，我们要完全将各类创建和初始化的逻辑都“封闭”掉，代码会臃肿到什么地步，而这部分“封闭”的逻辑在业务开发中我们完全使用不到，所以更建议以一种“约定由于配置”的方式来处理单例的创建问题。

综上，做到私有化构造方法这一步就够了，不需要过度开发。

3.2.懒汉式真的比饿汉式更佳吗？

懒汉式主要是为了做懒加载，当单例对象没有使用的时候就不创建和初始化，特别是初始化是需要加载的资源比较多、比较耗时的时候，用懒加载可以加快项目启动的速度，同时又能减少系统的资源浪费。
但是从另一个角度讲，如果不是在启动的时候初始化，那就是在客户端调用的时候初始化，想象一下一个高并发的互联网项目，如果在客户端调用的时候再做耗时的初始化动作，就可能造成接口的请求时间过长，接口超时等，会影响一批用户的使用体验。
另外，如果初始化的过程中存在一些异常情况，我们应该让问题在项目启动时就暴露出来，及时修复，而不是在用户使用的时候才暴露问题。

综上，在业务开发中或许饿汉式单例是更好的选择。

3.3.单例存在的问题

单例模式编写和使用都很简单，但是它也存在一些问题，例如：

面向对象支持不好：单例模式在作用范围内只有一个实例，那就无法通过创建更多的实例来使用面向对象的抽象、继承、多态等特性，更像是一种面向过程的写法。
违反开闭原则：无法拓展，每一次迭代都需要修改原有的代码。
违反单一职责：单例模式既创建对象、又管理对象，职责模糊，可能会导致代码变得复杂。

综上，单例模式存在一定的问题，如果存在拓展的需求就尽可能的避免使用单例模式。

但如果在不需要大量的拓展，又没有业务间的复杂依赖关系，使用单例模式就比较简洁方便也不失为一种选择，例如各种无状态的工具类。

4.其他作用范围的单例模式

4.1.线程内的单例

即单例对象在线程内时唯一的，线程之间不是唯一的，我们开发中有一种很常见的情况：线程局部变量，一般是通过ThreadLocal来做的。
实现原理也比较简单，其实就是使用一个全局的Map来保存对象，以线程对象thread为key，以需要保存的单例对象为value，这样就保证了一个线程只对应一个对象。
在业务流程中的用户登录信息，往往就是保存在ThreadLocal中的，另外PageHelper这个著名的工具类也是通过ThreadLocal来实现的。

如果想了解ThreadLocal的使用方式，可以参考我的另一篇博客《【并发编程】（九）线程安全的代码及ThreadLocal的使用》
如果想了解它详细的实现原理，可以参考《【并发编程】（十）线程局部变量——ThreadLocal原理详解》

4.2.进程间的单例

进程间的单例，更常用的一种说法分布式环境中的单例，这类需求我们使用的也比较多，其实现原理也比较简单，就是将单例对象通过序列化的方式存储在一个多个服务都会共同访问的存储区域中，例如一个共享的文件中、一些分布式的中间件中，例如redis、zk等等，而最常见的当然就是分布式锁。
我们只需要为单例对象创建出一个唯一标识，在每个服务中判断唯一标识是否存在即可。

5.“多例模式”

多例模式是单例模式中的一种特例，即可以在一定数量范围内创建类的多个实例，还有一层理解就是不同类型的对象可以创建多个，想通类型的对象只能创建一个，后者的概念使用的更多。

以日志打印为例，我们引入Slf4J后通过下面的方式获得一个日志对象：

private Logger logger = LoggerFactory.getLogger(xxx.class);

这里获取的logger如果后面的class对象相同，获取的就是同一个对象，这种方式更像是工厂模式，在代码中看到的也是工厂模式，如下图：
我们进入这个工厂模式的方法后，可以看到下面的代码：
在这里插入图片描述
这里就非常明显了，这就是一种单例模式的创建方式，通过一个Map将单例对象管理起来，如果Map中有就直接返回，如果没有就创建一个并放入到Map中，这里的对象都是logger对象，只是使用日志的类不一样，这就是多例模式的一种体现。