设计模式之美 - 单例模式
设计模式之美目录:https://www.cnblogs.com/binarylei/p/8999236.html
保证一个类只有一个实例,并且提供一个访可该实例的全局访问点。实现方式有三种:懒汉式、饿汉式、注册式(包括枚举)。应用场景如:Listener 本身单例、日历 Calender、IOC 容器、配置信息 Config。
在学习单例模式的过程中,思考如下两个问题:
- 为什么说饿汉式(提前初始化)优于懒汉式?
- 为什么不推荐使用单例模式?有何替代方案?
1. 单例实现方式
1.1 饿汉式单例
// 饿汉式单例类:在类初始化时,已经自行实例化
public class Singleton {
private Singleton() {}
private static final Singleton single = new Singleton();
// 静态工厂方法
public static Singleton getInstance() {
return single;
}
}
说明: 饿汉式在类创建时就已经创建好静态对象,以后不再改变,所以天生是线程安全的。有人觉得饿汉式单例不好,因为不支持延迟加载,如果实例占用资源多(比如占用内存多)或初始化耗时长(比如需要加载各种配置文件),提前初始化实例是一种浪费资源的行为。最好的方法应该在用到的时候再去初始化。不过,我个人并不认同这样的观点。
- 占用资源多:按照 fail-fast 设计原则,如果资源不够,就会在程序启动的时候触发报错(比如 Java 中的 PermGen Space OOM),避免在程序运行时,突然因为初始化这个实例占用资源过多,导致系统崩溃,影响系统的可用性。
- 初始化耗时长:避免程序运行时,突然初始化该类,导致响应时间变长。
汉式和懒汉式区别:
-
线程安全。饿汉式天生就是线程安全的,可以直接用于多线程而不会出现问题,懒汉式本身是非线程安全的,常用的保证单例线程安全的方案有 "double-check" 和 "静态内部类" 两种。
-
资源加载和性能。
1.2 懒汉式单例
/**
* 懒汉式单例类:在第一次调用的时候实例化自己
* 1. 构造器私有化,避免外面直接创建对象
* 2. 声明一个私有的静态变量
* 3. 创建一个对外的公共静态方法访问该变量,如果没有变量就创建对象
*/
public class Singleton {
private Singleton() {
}
private static Singleton single = null;
// 静态工厂方法
public static Singleton getInstance() {
if (single == null) {
single = new Singleton();
}
return single;
}
}
说明: Singleton 通过将构造方法限定为 private 避免了类在外部被实例化,在同一个虚拟机范围内,Singleton 的唯一实例只能通过 getInstance() 方法访问。事实上,通过 Java 反射机制是能够实例化构造方法为 private 的类的,那基本上会使所有的 Java 单例实现失效。此问题在此处不做讨论,姑且掩耳盗铃地认为反射机制不存在。
但是以上懒汉式单例的实现没有考虑线程安全问题,它是线程不安全的,并发环境下很可能出现多个 Singleton 实例,要实现线程安全,最简单粗暴的方法是在 getInstance 方法上加同步锁。
public class Singleton {
private Singleton() {}
private static Singleton single=null;
// 静态工厂方法
public static synchronized Singleton getInstance() {
if (single == null) {
single = new Singleton();
}
return single;
}
}
1.3 双重检查锁定
为处理同步延迟加载方式瓶颈问题,我们需要对 instance 进行第二次检查,目的是避开过多的同步(因为这里的同步只需在第一次创建实例时才同步,一旦创建成功,以后获取实例时就不需要同获取锁了),但在 Java 中行不通,因为同步块外面的 if (instance == null) 可能看到已存在,但不完整的实例。JDK5.0 以后版本若 instance 为 volatile 则可行:
public class Singleton {
private volatile static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {// 1
if (instance == null) { // 2
instance = new Singleton();// 3
}
}
}
return instance;
}
}
可以看到里面加了 volatile 关键字来声明单例对象,既然 synchronized 已经起到了多线程下原子性、有序性、可见性的作用,为什么还要加 volatile 呢,原因已经在下面评论中提到:
《单例模式与双重检测》:http://www.iteye.com/topic/652440
1.4 静态内部类
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
使用 Java 初始化类时的线程安全机,保障线程安全,同时避免了同步带来的性能影响。
1.5 枚举
枚举的本质是懒汉式单例,在类初始化时会实例对象。我们看一下枚举类反编译后的代码就一目了然:
本文使用 jad 工具进行反编译,下载地址:https://varaneckas.com/jad/
public final class SingletonEnum extends Enum {
private SingletonEnum(String s, int i) {
super(s, i);
}
public static final SingletonEnum A;
public static final SingletonEnum B;
public static final SingletonEnum C;
private static final SingletonEnum $VALUES[];
static {
A = new SingletonEnum("A", 0);
B = new SingletonEnum("B", 1);
C = new SingletonEnum("C", 2);
$VALUES = (new SingletonEnum[] { A, B, C });
}
}
1.6 注册式单例
Spring 内部使用注册式实现单例,枚举也是注册式。
// 类似 Spring 里面的方法,将类名注册,下次从里面直接获取。
public class Singleton {
private static Map<String, Singleton> map = new HashMap<String, Singleton>();
// 静态工厂方法,返还此类惟一的实例
public static Singleton getInstance(String name) {
if(map.get(name) == null) {
map.put(name, (Singleton) Class.forName(name).getInstance());
}
return map.get(name);
}
}
说明: 登记式单例实际上维护了一组单例类的实例,将这些实例存放在一个 Map 中,对于已经登记过的实例,则从 Map 直接返回,对于没有登记的,则先登记,然后返回。
2. 单例作用范围
2.1 进程内单例
Java 进行内单例为什么说都是 ClassLoader 级别的呢?
我理解单例的本质还是使用缓存将对象保存起来,单例的作用范围实际上看能不能缓存中获取这个对象。如线程内的单例,使用 ThreadLocal 进行缓存时,对其它线程不可见。而进程内单例,也就是普通的单例,无论是枚举或懒汉或贪婪模式都使用 static 进行缓存,而不同 ClassLoader 加载的静态空间实际上是不共享的,所以进程间的单例实际上是 ClassLoader 级别的。如果不同 ClassLoader 间的 static 静态空间共享,那么像 Tomcat 容器,每个应用都会初始化一个 ClassLoader 加载应用,不同应用之间就可能会相互修改其它应用的数据,这样会出很多问题。
2.2 线程内单例
使用 JDK 提供了 ThreadLocal 来保证线程内唯一。
2.3 集群内单例
- 单例对象序列化并存储到外部共享存储区(比如文件)。
- 进程在使用这个单例对象的时候,需要先从外部共享存储区中将它读取到内存,并反序列化成对象,然后再使用,使用完成之后还需要再存储回外部共享存储区。
- 为了保证任何时刻,在进程间都只有一份对象存在,一个进程在获取到对象之后,需要对对象加锁,避免其他进程再将其获取。在进程使用完这个对象之后,还需要显式地将对象从内存中删除,并且释放对对象的加锁。
3. 什么时候使用单例
其实,我一般不推荐使用单例模式。使用单例模式会带来很多问题。
- 单例对 OOP 特性的支持不友好。单例的使用方式违背了基于接口而非实现的设计原则,也就违背了广义上理解的 OOP 的抽象特性。在代码中直接使用 Singleton#getInstance() 获取实例对象,实际上是基于实现编程而非接口编程,也就是我们所说的硬编码。如果后续需要扩展其余的实现,那么项目中所以使用单例硬编码的地方都要修改。
- 单例会隐藏类之间的依赖关系。一般只能通过 Singleton#getInstance() 获取对象,隐藏依赖的对象。
- 单例对代码的扩展性不友好。比如数据库连接池如果设计为单例,刚开始我们应用可能只需要一个数据库连接池就可以了,随着应用变得复杂,此时我们需要连接好几个不同的数据库,此时一个单例就无法应对多个实例的情况。
- 单例对代码的可测试性不友好。单例的所有成员属性都相当于静态变量,这样每次单元测试时都需要手动重置单例,否则不同的单元测试会相互干扰。
既然单例存在这些问题,但项目又要使用单例,那怎么办呢?我总结了以下几种常用的方法:
-
程序员自己控制单例类的使用。只要不是提供给第三方使用,自己完全可以控制类的行为,没有必要专门设计成单例。
-
依赖注入:如 Spring IoC 默认就是单例。
-
工厂方法:工厂方法返回单例对象,这种方法其实也很常用。
public class RuleConfigParserFactory_v2 { private static final Map<String, IRuleConfigParser> cachedParsers = new HashMap<>(); static { cachedParsers.put("json", new JsonRuleConfigParser()); cachedParsers.put("xml", new XmlRuleConfigParser()); cachedParsers.put("yaml", new YamlRuleConfigParser()); cachedParsers.put("properties", new PropertiesRuleConfigParser()); } public static IRuleConfigParser createParser(String configFormat) { return cachedParsers.get(configFormat.toLowerCase()); } }
每天用心记录一点点。内容也许不重要,但习惯很重要!