目录
一、单例模式的应用场景
二、常见的单例模式
饿汉式单例
懒汉式模式
反射破坏单例
反序列化破坏单例
注册时单例
ThreadLocal 单例
三、本章小结
我们常用的开发框架中就有很多单例模式的应用场景，就拿最常用的Spring来说，ApplicationContext全局中就有且只有一个实例，J2EE中的ServletContext也一样。
饿汉式单例是在类加载的时候就立即初始化，并且创建单例对象。绝对线程安全，在线 程还没出现以前就是实例化了，不可能存在访问安全问题。
优点:没有加任何的锁、执行效率比较高，在用户体验上来说，比懒汉式更好。缺点:类加载的时候就初始化，不管用与不用都占着空间，浪费了内存，有可能占着茅 坑不拉屎。Spring的IOC中的ApplicationContext本身就是饿汉式的单例模式
public class HungrySingleton { //先静态、后动态 //先属性、后方法 //先上后下 private static final HungrySingleton hungrySingleton = new HungrySingleton(); private HungrySingleton(){} // 构造方法私有化 public static HungrySingleton getInstance(){ return hungrySingleton; } }上图是最简单的一个饿汉式的单例模式的构造方式，还有一种方式是放在静态代码快中
// 静态代码块单例模式 public class HungryStaticSingleton { private static final HungryStaticSingleton hungrySingleton; static { hungrySingleton = new HungryStaticSingleton(); } private HungryStaticSingleton(){} public static HungryStaticSingleton getInstance(){ return hungrySingleton; } }饿汉模式以上两种完全够用，适用于实例较少的模式中，如果过多会加大内存开销。
懒汉式单例的特点是:被外部类调用的时候内部类才会加载。通俗一点说就是用到我时候我才去创建。
/懒汉式单例 //在外部需要使用的时候才进行实例化 public class LazySimpleSingleton { private LazySimpleSingleton(){} //静态块，公共内存区域 private static LazySimpleSingleton lazy = null; public static LazySimpleSingleton getInstance(){ if(lazy == null){ lazy = new LazySimpleSingleton(); } return lazy; } }然后我们书写一个线程类
public class ExectorThread implements Runnable{ @Override public void run() { LazySimpleSingleton singleton = LazySimpleSingleton.getInstance(); System.out.println(Thread.currentThread().getName() + ":" + singleton); } }测试代码
public class LazySimpleSingletonTest { public static void main( Thread t1 = new Thread(new ExectorThread()); Thread t2 = new Thread(new ExectorThread()); t1.start(); t2.start(); System.out.println("End"); } }一定几率出现创建两个不同结果的情况，意味着上面的单例存在线程安全隐患。那么，我们如何来 优化代码，使得懒汉式单例在线程环境下安全呢?来看下面的代码，给 getInstance()加 上 synchronized 关键字，是这个方法变成线程同步方法：
public class LazySimpleSingleton { private LazySimpleSingleton(){} //静态块，公共内存区域 private static LazySimpleSingleton lazy = null; public synchronized static LazySimpleSingleton getInstance(){ if(lazy == null){ lazy = new LazySimpleSingleton(); } return lazy; } }但是，用 synchronized 加锁，在线程数量比较多情况下，如果 CPU 分配压力上升，会导致大批 量线程出现阻塞，从而导致程序运行性能大幅下降。那么，有没有一种更好的方式，既 兼顾线程安全又提升程序性能呢?答案是肯定的。我们来看双重检查锁的单例模式：
public class LazyDoubleCheckSingleton { private volatile static LazyDoubleCheckSingleton lazy = null; private LazyDoubleCheckSingleton(){} public static LazyDoubleCheckSingleton getInstance(){ if(lazy == null){ synchronized (LazyDoubleCheckSingleton.class){ if(lazy == null){ lazy = new LazyDoubleCheckSingleton(); } } } return lazy; } }但是，用到 synchronized 关键字，总归是要上锁，对程序性能还是存在一定影响的。难 道就真的没有更好的方案吗?当然是有的。我们可以从类初始化角度来考虑，看下面的 代码，采用静态内部类的方式:
//这种形式兼顾饿汉式的内存浪费，也兼顾 synchronized 性能问题 //完美地屏蔽了这两个缺点 public class LazyInnerClassSingleton { //默认使用 LazyInnerClassGeneral 的时候，会先初始化内部类 //如果没使用的话，内部类是不加载的 private LazyInnerClassSingleton(){} //每一个关键字都不是多余的 //static 是为了使单例的空间共享 //保证这个方法不会被重写，重载 public static final LazyInnerClassSingleton getInstance(){ //在返回结果以前，一定会先加载内部类 return LazyHolder.LAZY; } //默认不加载 private static class LazyHolder{ private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton(); } }大家有没有发现，上面介绍的单例模式的构造方法除了加上 private 以外，没有做任何处 理。如果我们使用反射来调用其构造方法，然后，再调用 getInstance()方法，应该就会 两个不同的实例。现在来看一段测试代码，以 LazyInnerClassSingleton 为例
public class LazyInnerClassSingletonTest { public static void main(String[] args) { try{ //很无聊的情况下，进行破坏 Class<?> clazz = LazyInnerClassSingleton.class; //通过反射拿到私有的构造方法 Constructor c = clazz.getDeclaredConstructor(null); //强制访问，强吻，不愿意也要吻 c.setAccessible(true); //暴力初始化 Object o1 = c.newInstance(); //调用了两次构造方法，相当于 new 了两次 //犯了原则性问题， Object o2 = c.newInstance(); System.out.println(o1 == o2); }catch (Exception e){ e.printStackTrace(); } } }答案肯定是 false，现在，我们在其构造方法中做一些限制，一旦出现多 次重复创建，则直接抛出异常。来看优化后的代码:
//史上最牛 B 的单例模式的实现方式 public class LazyInnerClassSingleton { //默认使用 LazyInnerClassGeneral 的时候，会先初始化内部类 //如果没使用的话，内部类是不加载的 private LazyInnerClassSingleton(){ if(LazyHolder.LAZY != null){ throw new RuntimeException("不允许创建多个实例"); } } //每一个关键字都不是多余的 //static 是为了使单例的空间共享 //保证这个方法不会被重写，重载 public static final LazyInnerClassSingleton getInstance(){ //在返回结果以前，一定会先加载内部类 return LazyHolder.LAZY; } //默认不加载 private static class LazyHolder{ private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton(); } }当我们将一个单例对象创建好，有时候需要将对象序列化然后写入到磁盘，下次使用时 再从磁盘中读取到对象，反序列化转化为内存对象。反序列化后的对象会重新分配内存， 即重新创建。那如果序列化的目标的对象为单例对象，就违背了单例模式的初衷，相当 于破坏了单例，来看一段代码:
//反序列化时导致单例破坏 public class SeriableSingleton implements Serializable { public final static SeriableSingleton INSTANCE = new SeriableSingleton(); private SeriableSingleton(){} public static SeriableSingleton getInstance() { return INSTANCE; } } public class SeriableSingletonTest { public static void main(String[] args) { SeriableSingleton s1 = null; SeriableSingleton s2 = SeriableSingleton.getInstance(); FileOutputStream fos = null; try { fos = new FileOutputStream("SeriableSingleton.obj"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeObject(s2); oos.flush(); oos.close(); FileInputStream fis = new FileInputStream("SeriableSingleton.obj"); ObjectInputStream ois = new ObjectInputStream(fis); s1 = (SeriableSingleton)ois.readObject(); ois.close(); System.out.println(s1); System.out.println(s2); System.out.println(s1 == s2); } catch (Exception e) { e.printStackTrace(); } } }运行结果中，反序列化后的对象和手动创建的对象是不一致的，实例化了两 次，违背了单例的设计初衷。那么，我们如何保证序列化的情况下也能够实现单例?其实很简单，只需要增加 readResolve()方法即可。来看优化代码:
public class SeriableSingleton implements Serializable { public final static SeriableSingleton INSTANCE = new SeriableSingleton(); private SeriableSingleton(){} public static SeriableSingleton getInstance(){ return INSTANCE; } private Object readResolve(){ return INSTANCE; } }那么，为什么这样就能解决返序列化破坏单例呢，我们一起看JDK源码来寻找答案：
ObjectInputStream 类的 readObject()方法，代码如下：
我们发现在 readObject 中又调用了我们重写的 readObject0()方法。进入 readObject0() 方法，代码如下:
我们看到 TC_OBJECTD 中判断，调用了 ObjectInputStream 的 readOrdinaryObject() 方法，我们继续进入看源码:
发现调用了 ObjectStreamClass 的 isInstantiable()方法，而 isInstantiable()里面的代码 如下:
很简单，就是判断当前是否包含无参构造，如果存在就会被实例化，其实还没有找到为什么加上 readResolve()方法就避免了单例被破坏的真正原 因。我再回到 ObjectInputStream 的 readOrdinaryObject()方法继续往下看：
判断无参构造方法是否存在之后，又调用了 hasReadResolveMethod()方法，来看代码:
逻辑非常简单，就是判断 readResolveMethod 是否为空，不为空就返回 true。那么 readResolveMethod 是在哪里赋值的呢?通过全局查找找到了赋值代码在私有方法 ObjectStreamClass()方法中给 readResolveMethod 进行赋值，来看代码:
上面的逻辑其实就是通过反射找到一个无参的 readResolve()方法，并且保存下来。现在 再 回 到 ObjectInputStream 的 readOrdinaryObject() 方 法 继 续 往 下 看 ， 如 果 readResolve()存在则调用 invokeReadResolve()方法，来看代码:
我们可以看到在 invokeReadResolve()方法中用反射调用了 readResolveMethod 方法。 通过 JDK 源码分析我们可以看出，虽然，增加 readResolve()方法返回实例，解决了单 例被破坏的问题。但是，我们通过分析源码以及调试，我们可以看到实际上实例化了两 次，只不过新创建的对象没有被返回而已。那如果，创建对象的动作发生频率增大，就意味着内存分配开销也就随之增大，难道真的就没办法从根本上解决问题吗?下面我们 来注册式单例也许能帮助到你。
注册式单例又称为登记式单例，就是将每一个实例都登记到某一个地方，使用唯一的标 识获取实例。注册式单例有两种写法:一种为容器缓存，一种为枚举登记。先来看枚举 式单例的写法，来看代码，创建 EnumSingleton 类
public enum EnumSingleton { INSTANCE; private Object data; public Object getData() { return data; } public void setData(Object data) { this.data = data; } public static EnumSingleton getInstance() { return INSTANCE; } }那么，枚举类是如何实现单例的呢，我们需要反编译其的class文件进行查看，如下：
static { INSTANCE = new EnumSingleton("INSTANCE", 0); $VALUES = (new EnumSingleton[] { INSTANCE }); }原来，枚举式单例在静态代码块中就给 INSTANCE 进行了赋值，是饿汉式单例的实现。 至此，我们还可以试想，序列化我们能否破坏枚举式单例呢?我们不妨再来看一下 JDK 源码，还是回到 ObjectInputStream 的 readObject0()方法:
我们看到在 readObject0()中调用了 readEnum()方法，来看 readEnum()中代码实现:
我们发现枚举类型其实通过类名和 Class 对象类找到一个唯一的枚举对象。因此，枚举对 象不可能被类加载器加载多次。那么反射是否能破坏枚举式单例呢?
还是习惯性地想来看看 JDK 源码，进入 Constructor 的 newInstance()方法:
在 newInstance()方法中做了强制性的判断，如果修饰符是 Modifier.ENUM 枚举类型， 直接抛出异常。到这为止，我们是不是已经非常清晰明了呢?枚举式单例也是《Effective Java》书中推荐的一种单例实现写法。在 JDK 枚举的语法特殊性，以及反射也为枚举保 驾护航，让枚举式单例成为一种比较优雅的实现。
接下来看注册式单例还有另一种写法，容器缓存的写法，创建 ContainerSingleton 类:
public class ContainerSingleton { private ContainerSingleton(){} private static Map<String,Object> ioc = new ConcurrentHashMap<String,Object>(); public static Object getBean(String className){ synchronized (ioc) { if (!ioc.containsKey(className)) { Object obj = null; try { obj = Class.forName(className).newInstance(); ioc.put(className, obj); } catch (Exception e) { e.printStackTrace(); } return obj; } else { return ioc.get(className); } } } }容器式写法适用于创建实例非常多的情况，便于管理。但是，是非线程安全的。
在主线程 main 中无论调用多少次，获取到的实例都是同一个，都在子线程中分别获取到了不同的实例。那么 ThreadLocal 是如果实现这样的效果的呢?我们知道上面的单例模式为了达到线程安全的目的，给方法上锁，以时间换空间。ThreadLocal 将所有的对象全部放在 ThreadLocalMap 中，为每个线程都提供一个对象，实际上是以空间换时间来实现线程间隔离的。
单例模式可以保证内存里只有一个实例，减少了内存开销;可以避免对资源的多重占用。 单例模式看起来非常简单，实现起来其实也非常简单。但是在面试中却是一个高频面试 题。希望小伙伴们通过本章的学习，对单例模式有非常深刻的掌握，在面试中彰显技术 深度，提升核心竞争力，给面试加分，顺利拿到 Offer。
