设计模式 | 单例模式的初步学习
单例模式
单例模式的概念
定义: 单例模式(Singleton)是指 一个类只能有一个实例
,且该类能 自行创建
这个实例。
角色:
单例模式的主要角色有:
- 单例类:包含一个实例且能自行创建这个实例的类。
- 访问者类:使用单例的类。
特点:
- 单例类只有一个实例对象;
- 该单例对象必须由单例类自行创建;
- 单例类对外提供一个访问该单例的全局访问点。
普通类的构造函数是公有的,外部类可以通过"new 构造函数()" 来生成多个实例。但是,如果将类的构造函数设为私有
,外部类就无法调用构造函数生成多个实例了。这时类自身必须提供一个静态私有实例
,并且向外提供一个静态公有函数创建和调用该静态私有实例。
单例模式的实现
懒汉式-线程不安全
以下实现中,私有静态变量 uniqueInstance 被延迟实例化,这样做的好处是:如果没有用到该类,那么 uniqueInstance 就不会被实例化,节省内存。
这个实现在多线程的环境下是不安全的,因为如果多个能够同时进入if(uniqueInstance == null) ,并且此时 uniqueInstance == null,那么会有多个线程执行 uniqueInstance = new Singleton(); 语句,这将导致实例化多次 uniqueInstance。
public class LazySingleton {
private static LazySingleton uniqueInstance;
private LazySingleton() {
}
public static LazySingleton getInstance() {
if(uniqueInstance == null) {
uniqueInstance = new LazySingleton();
}
return uniqueInstance;
}
}
饿汉式-线程安全
线程不安全的问题主要是 uniqueInstance 被实例化多次,采取直接实例化 uniqueInstance 的方法就可以避免线程不安全的情况发生。
但这样也就丧失了延迟实例化所带来的节约资源的好处。
public class HungrySingleton {
private static HungrySingleton uniqueInstance = new HungrySingleton();
private HungrySingleton() {}
public static HungrySingleton getInstance() {
return uniqueInstance;
}
}
懒汉式-线程安全
只要对 getInstance() 方法加锁,那么在一个时间点只能有一个线程进入该方法,从而避免了实例化多次 uniqueInstance。
但是当一个线程进入该方法后,其他进入该方法的线程都必须等待,即使 uniqueInstance 被实例化过了。这会让线程阻塞时间过长,因此该方法有性能问题,不推荐使用。
public class LazySingleton {
private static LazySingleton uniqueInstance;
private LazySingleton() {
}
public static synchronized LazySingleton getInstance() {
if(uniqueInstance == null) {
uniqueInstance = new LazySingleton();
}
return uniqueInstance;
}
}
双重校验锁(Double Check Lock)-线程安全
直接对方法进行加锁,会让线程阻塞时间过长。我们可以用同步代码块
的方式解决这个问题,对 uniqueInstance = new LazySingleton(); 加锁,这样在 uniqInstance被实例一次后,就不会出现线程阻塞问题。
public class LazySingleton {
private volatile static LazySingleton uniqueInstance;
private LazySingleton() {
}
public static LazySingleton getInstance() {
if(uniqueInstance == null) {
synchronized (LazySingleton.class) {
if(uniqueInstance == null) {
uniqueInstance = new LazySingleton();
}
}
}
return uniqueInstance;
}
}
考虑下面的实现,也就是只使用了一个 if 语句。在 uniqueInstance == null 的情况下,如果两个线程都执行了 if 语句,那么两个线程都会进入 if 语句块内
。虽然在 if 语句块内有加锁操作,但是两个线程都会执行 uniqueInstance = new LazySingleton(); 这条语句,只是先后的问题,那么就会进行两次实例化。因此必须使用双重校验锁
,也就是需要使用两个 if 语句。
if (uniqueInstance == null) {
synchronized (Singleton.class) {
uniqueInstance = new Singleton();
}
}
uniqueInstance 采用 volatile 关键字修饰也是很有必要的, uniqueInstance = new Singleton(); 这段代码其实是分为三步执行:
- 为 uniqueInstance 分配内存空间
- 初始化 uniqueInstance
- 将 uniqueInstance 指向分配的内存地址
但是由于 JVM 具有 指令重排
的特性,执行顺序有可能变成 1>3>2。指令重排在单线程环境下不会出现问题,但是在多线程环境下会导致一个线程获得还没有初始化的实例。
例如,线程 T1 执行了 1 和 3,此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空,因此返回 uniqueInstance,但此时 uniqueInstance 还未被初始化。
使用 volatile 可以禁止 JVM 的指令重排,保证在多线程环境下也能正常运行。
静态内部类的实现
当 Singleton 类加载时,静态内部类 SingletonHolder 没有被加载进内存。只有当调用 getUniqueInstance() 方法从而触发 SingletonHolder.INSTANCE 时 SingletonHolder 才会被加载,此时初始化 INSTANCE 实例,并且 JVM 能确保 INSTANCE 只被实例化一次。
这种方式不仅具有延迟初始化的好处,而且由 JVM 提供了对线程安全的支持。
//静态内部类
public class Singleton {
private Singleton() {}
private static class SingleHolder {
private static final Singleton Instance = new Singleton();
}
public static Singleton getInstance() {
return SingleHolder.Instance;
}
}
静态内部类的优点是:外部类加载时并不需要立即加载内部类,内部类不被加载则不去初始化INSTANCE,故而不占内存。即当SingleTon第一次被加载时,并不需要去加载SingleTonHoler,只有当getInstance()方法第一次被调用时,才会去初始化INSTANCE
,第一次调用getInstance()方法会导致虚拟机加载SingleTonHoler类,这种方法不仅能确保线程安全,也能保证单例的唯一性,同时也延迟了单例的实例化。
那么,静态内部类又是如何实现线程安全的呢?首先,我们先了解下类的加载时机。
类加载时机:JAVA虚拟机在有且仅有的5种场景下会对类进行初始化。
- 遇到new、getstatic、setstatic或者invokestatic这4个字节码指令时,对应的java代码场景为:new一个关键字或者一个实例化对象时、读取或设置一个静态字段时(final修饰、已在编译期把结果放入常量池的除外)、调用一个类的静态方法时。
- 使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没进行初始化,需要先调用其初始化方法进行初始化。
- 当初始化一个类时,如果其父类还未进行初始化,会先触发其父类的初始化。
- 当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的类),虚拟机会先初始化这个类。
- 当使用JDK 1.7等动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。
这5种情况被称为是类的主动引用,注意,这里《虚拟机规范》中使用的限定词是"有且仅有",那么,除此之外的所有引用类都不会对类进行初始化,称为被动引用。静态内部类就属于被动引用的行列。
我们再回头看下getInstance()方法,调用的是SingleTonHoler.INSTANCE,取的是SingleTonHoler里的INSTANCE对象,跟上面那个DCL方法不同的是,getInstance()方法并没有多次去new对象,故不管多少个线程去调用getInstance()方法,取的都是同一个INSTANCE对象,而不用去重新创建。当getInstance()方法被调用时,SingleTonHoler才在SingleTon的运行时常量池里,把符号引用替换为直接引用,这时静态对象INSTANCE也真正被创建,然后再被getInstance()方法返回出去,这点同饿汉模式。那么INSTANCE在创建过程中又是如何保证线程安全的呢?在《深入理解JAVA虚拟机》中,有这么一句话:
虚拟机会保证一个类的()方法在多线程环境中被正确地加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的()方法,其他线程都需要阻塞等待,直到活动线程执行()方法完毕。如果在一个类的()方法中有耗时很长的操作,就可能造成多个进程阻塞(需要注意的是,其他线程虽然会被阻塞,但如果执行()方法后,其他线程唤醒之后不会再次进入()方法。同一个加载器下,一个类型只会初始化一次。),在实际应用中,这种阻塞往往是很隐蔽的。
故而,可以看出INSTANCE在创建过程中是线程安全的,所以说静态内部类形式的单例可保证线程安全,也能保证单例的唯一性,同时也延迟了单例的实例化。
那么,是不是可以说静态内部类单例就是最完美的单例模式了呢?其实不然,静态内部类也有着一个致命的缺点,就是传参的问题,由于是静态内部类的形式去创建单例的,故外部无法传递参数进去,例如Context这种参数,所以,我们创建单例时,可以在静态内部类与DCL模式里自己斟酌。
枚举实现【这个没学会】
package singleton;
//静态内部类
public enum Singleton {
INSTANCE;
private String objName;
public String getObjName() {
return objName;
}
public void setObjName(String objName) {
this.objName = objName;
}
public static void main(String[] args) {
// 单例测试
Singleton firstSingleton = Singleton.INSTANCE;
firstSingleton.setObjName("firstName");
System.out.println(firstSingleton.getObjName());
Singleton secondSingleton = Singleton.INSTANCE;
secondSingleton.setObjName("secondName");
System.out.println(firstSingleton.getObjName());
System.out.println(secondSingleton.getObjName());
// 反射获取实例测试
try {
Singleton[] enumConstants = Singleton.class.getEnumConstants();
for (Singleton enumConstant : enumConstants) {
System.out.println(enumConstant.getObjName());
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
输出结果:
该实现在多次序列化再进行反序列化之后,不会得到多个实例。而其它实现需要使用 transient 修饰所有字段,并且实现序列化和反序列化的方法。
该实现可以防止反射攻击。在其它实现中,通过 setAccessible() 方法可以将私有构造函数的访问级别设置为 public,然后调用构造函数从而实例化对象,如果要防止这种攻击,需要在构造函数中添加防止多次实例化的代码。该实现是由 JVM 保证只会实例化一次,因此不会出现上述的反射攻击。