单例模式是我们日常接触的最常见的一种创建型设计模式,spring IoC 容器中的 bean 实例默认就是单例的。采用单例模式可以降低大量非必须对象创建带来的内存开销。本篇主要从单例的常见实现方式及各种方式存在的问题进行分析。
单例的特点:
- 私有化构造方法;
- 全局唯一的实例;
- 对外提供唯一实例的访问点。
1. 懒汉式单例
懒汉是单例顾名思义就是延迟实例化,只在使用的时候才进行实例化。
下面这种方式的懒汉式单例是懒汉式单例的常见实现方式,这种方式需要我们自己编码来保证线程安全,同时还要防止暴力反射对单例的破坏。
public class LazySingleton {
// 懒汉式是线程不安全的,因此需要我们自己编码确保安全性。
// 使用内存屏障,确保线程每次读到的是最新的值。
private static volatile LazySingleton INSTANCE;
private LazySingleton(){
// 避免暴力反射破坏单例
if (INSTANCE != null) {
throw new RuntimeException("instance has been created!");
}
}
public static LazySingleton getInstance(){
// DCL 确保线程安全同时兼顾效率
if (INSTANCE == null) {
synchronized (LazySingleton.class) {
if (INSTANCE == null) {
INSTANCE = new LazySingleton();
}
}
}
return INSTANCE;
}
}
上面的懒汉是单例的实现方式,在获取实例的类方法中使用 DCL 实现线程安全,这种方式看起来不是那么优雅,下面这种方式看起来要稍微优雅些。
public class InnerHolderLazySingleton {
private InnerHolderLazySingleton(){
// 避免暴力反射破坏单例
if (Holder.INSTANCE != null) {
throw new RuntimeException("instance has been created!");
}
}
public static InnerHolderLazySingleton getInstance() {
// 对于当前类来说,对象的创建是懒汉式的,只有访问此方法时 Holder 类才会被加载,
// Holder 被加载的时候类属性 INSTANCE 才会被创建。
// 对于内部类来说,对象的创建是饿汉式的,类加载时就创建 INSTANCE 实例。
return Holder.INSTANCE;
}
static class Holder {
private static final InnerHolderLazySingleton INSTANCE
= new InnerHolderLazySingleton();
}
}
上面这种方式巧妙的利用了 JVM 类加载的特点实现了线程安全。
2. 饿汉式单例
饿汉式单例顾名思义就是类加载的时候就创建类的实例,这种方式的单例不存在线程安全问题,因为 JVM 会保证类加载的线程安全。但是这种方式的单例有一个弊端,会创建一些使用不到的类,如果想应用中存在大量使用不到的饿汉式单例,会造成一定的内存空间的浪费。
public class HungrySingleton {
// 饿汉式使用虚拟机的类加载机制来确保对象创建的安全性。
// 但是同时也造成了浪费内存的风险,不管对象是否会被使用,都会被创建。
private static final HungrySingleton INSTANCE = new HungrySingleton();
private HungrySingleton(){
// 避免暴力反射破坏单例
if (INSTANCE != null) {
throw new RuntimeException("instance has been created!");
}
}
public static HungrySingleton getInstance() {
return INSTANCE;
}
}
3. 注册式单例
注册式单例的实现方式其实就是 spring IoC 容器的原型,只要保证容器的全局唯一性就可以确保单例的全局唯一性。使用这种方式的单例,我们需要引导应用层使用规范的方式获取对象的实例。
public class RegistrySingletonContainer {
// 确保容器的全局唯一性,至少对于同一个类加载器下的所有类来说是这样
private static final Map<String, Object> container = new ConcurrentHashMap<>();
private static final Object instantiateMonitor = new Object();
public static Object getInstance(String className) {
// 首次查找时创建,懒加载
if (!container.containsKey(className)) {
synchronized (instantiateMonitor) {
if (!container.containsKey(className)) {
Object instance = null;
try {
Class clazz = Class.forName(className);
instance = clazz.newInstance();
} catch (ClassNotFoundException e) {
// ignore
} catch (IllegalAccessException e) {
// ignore
} catch (InstantiationException e) {
// ignore
}
container.put(className, instance);
}
}
}
return container.get(className);
}
}
4. 枚举式单例
上面的几种单例的实现方式,除了各自特有的问题外,都有这些共同的问题——反射及序列化和反序列化对单例的破坏。如果要保证单例不被破坏我们必须自行处理,这样的处理明显不够优雅。枚举式单例优雅地解决了所有这些问题。
枚举式单例是注册式单例的一种实现方式,这种注册和查找由 JVM 预置处理帮我们完成,同时帮我们做了反射破坏的保护机制以及序列化破坏的保护机制。
public enum EnumSingleton {
// 枚举形式的单例其实也是注册式单例的一种形式,
// 只不过这种注册机制被 JVM 内置化了,同时也进行了反射破坏的保护处理。
// 这种单例的实现方式也是《Effective Java》一书中推荐的方式。
INSTANCE;
public static EnumSingleton getInstance() {
return INSTANCE;
}
}
在 JVM 中,被声明为 enum 类型的枚举类,隐式地继承了 Enum 类。
// Enum 的构造函数
protected Enum(String name, int ordinal) {
this.name = name;
this.ordinal = ordinal;
}
// 查找枚举类的实例
public static <T extends Enum<T>> T valueOf(Class<T> enumType,
String name) {
// 从容器中查找,这个容器预置在 Class 对象中。
T result = enumType.enumConstantDirectory().get(name);
if (result != null)
return result;
if (name == null)
throw new NullPointerException("Name is null");
throw new IllegalArgumentException(
"No enum constant " + enumType.getCanonicalName() + "." + name);
}
// 下面这两个方法实现了序列化和反序列化破坏单例的保护机制。
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
throw new InvalidObjectException("can't deserialize enum");
}
private void readObjectNoData() throws ObjectStreamException {
throw new InvalidObjectException("can't deserialize enum");
}
我们看下反射破坏的保护机制是如何实现的:
Constructor.newInstance()
public T newInstance(Object ... initargs)
throws InstantiationException, IllegalAccessException,
IllegalArgumentException, InvocationTargetException
{
if (!override) {
if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
Class<?> caller = Reflection.getCallerClass();
checkAccess(caller, clazz, null, modifiers);
}
}
// 这里会对类的标识符进行判断,如果类被标识成枚举,不允许通过反射创建实例
if ((clazz.getModifiers() & Modifier.ENUM) != 0)
throw new IllegalArgumentException("Cannot reflectively create enum objects");
ConstructorAccessor ca = constructorAccessor; // read volatile
if (ca == null) {
ca = acquireConstructorAccessor();
}
@SuppressWarnings("unchecked")
T inst = (T) ca.newInstance(initargs);
return inst;
}
通过上面的分析,我们可以理解为什么《Effective Java》一书中,作者推荐我们使用枚举来实现单例——这种方式是最优雅的,JVM 为我们预置处理好了单例模式可能出现的所有问题。
5. ThreadLocal 式单例
ThreadLocal 式单例并不是严格意义上的单例,它只做到了线程级别的单例,即同一个线程中,全局唯一,也因此这种方式不存在线程安全问题,也无需考虑反射及序列化反序列化的破坏。
public class ThreadLocalSingleton extends ThreadLocal<ThreadLocalSingleton> {
@Override
protected ThreadLocalSingleton initialValue() {
return new ThreadLocalSingleton();
}
}
6. 总结对比
实现方式 | 优点 | 缺点 |
---|---|---|
饿汉式 | 无需考虑安全问题 | 可能造成空间浪费,需要考虑反射、序列化和反序列化对单例的破坏 |
普通懒汉式 | 按需创建,节约内存 | 需要考虑线程安全问题,反射、序列化和反序列化对单例的破坏 |
内部类懒汉式 | 按需创建,节约内存,完美实现线程安全 | 需要考虑反射、序列化和反序列化对单例的破坏 |
注册式 | 按需创建,节约内存,无需考虑反射、序列化和反序列化对单例的破坏 | 需要考虑线程安全问题 |
枚举式 | 完美地实现了线程安全,无需考虑反射、序列化和反序列化对单例的破坏 | 可能造成空间浪费 |
ThreadLoal 式 | 不存在线程安全问题,无需考虑反射、序列化和反序列化对单例的破坏 | 只做到了线程级别的单例,高并发下会导致大量实例的创建 |