共计 11254 个字符，预计需要花费 29 分钟才能阅读完成。
[TOC]
1. 单例是什么？
单例模式：是一种创立型设计模式，目标是保障全局一个类只有一个实例对象，分为懒汉式和饿汉式。所谓懒汉式，相似于懒加载，须要的时候才会触发初始化实例对象。而饿汉式正好相同，我的项目启动，类加载的时候，就会创立初始化单例对象。
1.1 长处
如果只有一个实例，那么就能够少占用系统资源，节俭内存，拜访也会绝对较快。比拟灵便。
1.2 毛病
不能应用在变动的对象上，特地是不同申请会造成不同属性的对象。因为 Spring 自身默认实例就是单例的，所以应用的时候须要判断利用场景，要不会造成张冠李戴的景象。而往往操作援用和汇合，就更不容易查找到这种诡异的问题。例如：一些配置获取，如果前期应用须要批改其值，要么定义应用单例，前期应用深拷贝，要么不要应用单例。
既然应用单例模式，那么就得想尽一切办法，保障实例是惟一的，这也是单例模式的使命。然而代码是人写的，再完满的人也可能写出不那么完满的代码，再平安的零碎，也有可能存在破绽。既然你想保障单例，那我偏偏找出办法，创立同一个类多个不同的对象呢？这就是对单例模式的毁坏，到底有哪些形式能够毁坏单例模式呢？次要然而不限于以下几种：
- 没有将结构器私有化，能够间接调用。
- 反射调用结构器
- 实现了
cloneable接口 - 序列化与反序列化
2. 毁坏单例的几种办法
2.1 通过结构器创建对象
一般来说，一个略微 ✔️ 的单例模式，是不能够通过 new 来创建对象的，这个严格意义上不属于单例模式的毁坏。然而人不是完满的，写出的程序也不可能是完满的，总会有时候忽略了，遗记了将结构器私有化，那么内部就能够间接调用到结构器，天然就能够毁坏单例模式，所以这种写法就是不胜利的单例模式。
/**
* 上面是应用双重校验锁形式实现单例
*/
public class Singleton{
private volatile static Singleton singleton;
public static Singleton getSingleton() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();
}
}
}
return singleton;
}
}下面就是应用双重检察锁的形式，实现单例模式，然而遗记了写 private 的结构器，默认是有一个 public 的结构器，如果调用会怎么样呢？
public static void main(String[] args) {Singleton singleton = new Singleton();
Singleton singleton1 = new Singleton();
System.out.println(singleton.hashCode());
System.out.println(singleton1.hashCode());
System.out.println(Singleton.getSingleton().hashCode());
}运行的后果如下：
692404036
1554874502
1846274136三个对象的 hashcode 都不一样，所以它们不是同一个对象，这样也就证实了，这种单例写法是不胜利的。
2.2 反射调用结构器
如果单例类曾经将构造方法申明成为private，那么临时无奈显式的调用到构造方法了，然而真的没有其余办法能够毁坏单例了么？
答案是有！也就是通过反射调用构造方法，批改权限。
比方一个看似完满的单例模式：
import java.io.Serializable;
public class Singleton{
private volatile static Singleton singleton;
private Singleton(){}
public static Singleton getSingleton() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();
}
}
}
return singleton;
}
}测试代码如下：
import java.lang.reflect.Constructor;
public class SingletonTests {public static void main(String[] args) throws Exception {Singleton singleton = Singleton.getSingleton();
Singleton singleton1=Singleton.getSingleton();
Constructor constructor=Singleton.class.getDeclaredConstructor(null);
constructor.setAccessible(true);
Singleton singleton2 =(Singleton) constructor.newInstance(null);
System.out.println(singleton.hashCode());
System.out.println(singleton1.hashCode());
System.out.println(singleton2.hashCode());
}
}运行后果：
692404036
692404036
1554874502从后果咱们能够看出：喷射的确能够调用到曾经私有化的结构器，并且结构出不同的对象，从而毁坏单例模式。
那这种状况有没有什么办法能够避免毁坏呢？既然要避免毁坏，必定要避免调用公有结构器，也就是调用一次之后，再调用就报错，抛出异样。咱们的单例模式能够写成这样：
import java.io.Serializable;
public class Singleton {
private static int num = 0;
private volatile static Singleton singleton;
private Singleton() {synchronized (Singleton.class) {if (num == 0) {num++;} else {throw new RuntimeException("Don't use this method");
}
}
}
public static Singleton getSingleton() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();
}
}
}
return singleton;
}
}测试调用办法不变，测试后果如下, 反射调用的时候抛出异样了，阐明可能无效阻止反射调用毁坏单例的模式：
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at singleton.SingletonTests.main(SingletonTests.java:11)
Caused by: java.lang.RuntimeException: Don't use this method
at singleton.Singleton.<init>(Singleton.java:15)
... 5 more2.3 实现了 cloneable 接口
如果单例对象曾经将构造方法申明成为 private，并且重写了构造方法，那么临时无奈调用到构造方法。然而还有一种状况，那就是拷贝，拷贝的时候是不须要通过构造方法的。然而要想拷贝，必须实现Clonable 办法，而且须要重写 clone 办法。
import java.io.Serializable;
public class Singleton implements Cloneable {
private static int num = 0;
private volatile static Singleton singleton;
private Singleton() {synchronized (Singleton.class) {if (num == 0) {num++;} else {throw new RuntimeException("Don't use this method");
}
}
}
public static Singleton getSingleton() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();
}
}
}
return singleton;
}
@Override
protected Object clone() throws CloneNotSupportedException {return super.clone();
}
}测试代码如下：
public class SingletonTests {public static void main(String[] args) throws Exception {Singleton singleton1=Singleton.getSingleton();
System.out.println(singleton1.hashCode());
Singleton singleton2 = (Singleton) singleton1.clone();
System.out.println(singleton2.hashCode());
}
}运行后果如下，两个对象的 hashCode 不统一，也就证实了如果继承了 Cloneable 接口的话，并且重写了 clone() 办法，则该类的单例就能够被突破，能够创立出不同的对象。然而，这个 clone 的形式毁坏单例，看起来更像是 本人被动毁坏单例模式, 什么意思？
也就是如果很多时候，咱们只想要单例，然而有极少的状况，咱们想要多个对象，那么咱们就能够应用这种形式，更像是给本人留了一个后门，能够认为是一种良性的毁坏单例的形式。
2.4 序列化毁坏单例
序列化，实际上和 clone 差不多，然而不一样的中央在于咱们很多对象都是必须实现序列化接口的，然而实现了序列化接口之后，对单例的保障有什么危险呢？
危险就是序列化之后，再反序列化回来，对象的内容是一样的，然而对象却不是同一个对象了。不信？那就试试看：
单例定义如下：
import java.io.Serializable;
public class Singleton implements Serializable {
private static int num = 0;
private volatile static Singleton singleton;
private Singleton() {synchronized (Singleton.class) {if (num == 0) {num++;} else {throw new RuntimeException("Don't use this method");
}
}
}
public static Singleton getSingleton() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();
}
}
}
return singleton;
}
}测试代码如下：
import java.io.*;
import java.lang.reflect.Constructor;
public class SingletonTests {public static void main(String[] args) throws Exception {Singleton singleton1 = Singleton.getSingleton();
ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("file"));
objectOutputStream.writeObject(singleton1);
File file = new File("tempFile");
ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream(file));
Singleton singleton2 = (Singleton) objectInputStream.readObject();
System.out.println(singleton1.hashCode());
System.out.println(singleton2.hashCode());
}
}下面的代码，先将对象序列化到文件，再从文件反序列化回来，后果如下：
2055281021
1198108795后果证实：两个对象的 hashCode 不一样，阐明这个类的单例被毁坏了。
那么有没有办法在这种状况下，避免单例的毁坏呢？答案是：有！！！。
既然调用的是 objectInputStream.readObject() 来反序列化，那么咱们看看外面的源码, 外面调用了 readObject() 办法。
public final Object readObject()
throws IOException, ClassNotFoundException {return readObject(Object.class);
}readObject()办法，外面调用了 readObject0() 办法：
private final Object readObject(Class<?> type)
throws IOException, ClassNotFoundException
{if (enableOverride) {return readObjectOverride();
}
if (! (type == Object.class || type == String.class))
throw new AssertionError("internal error");
// if nested read, passHandle contains handle of enclosing object
int outerHandle = passHandle;
try {
// 序列化对象
Object obj = readObject0(type, false);
handles.markDependency(outerHandle, passHandle);
ClassNotFoundException ex = handles.lookupException(passHandle);
if (ex != null) {throw ex;}
if (depth == 0) {vlist.doCallbacks();
}
return obj;
} finally {
passHandle = outerHandle;
if (closed && depth == 0) {clear();
}
}
}readObject0()外部如下，其实是针对不同的类型别离解决：
private Object readObject0(Class<?> type, boolean unshared) throws IOException {boolean oldMode = bin.getBlockDataMode();
if (oldMode) {int remain = bin.currentBlockRemaining();
if (remain > 0) {throw new OptionalDataException(remain);
} else if (defaultDataEnd) {
/*
* Fix for 4360508: stream is currently at the end of a field
* value block written via default serialization; since there
* is no terminating TC_ENDBLOCKDATA tag, simulate
* end-of-custom-data behavior explicitly.
*/
throw new OptionalDataException(true);
}
bin.setBlockDataMode(false);
}
byte tc;
while ((tc = bin.peekByte()) == TC_RESET) {bin.readByte();
handleReset();}
depth++;
totalObjectRefs++;
try {switch (tc) {
// null
case TC_NULL:
return readNull();
// 援用类型
case TC_REFERENCE:
// check the type of the existing object
return type.cast(readHandle(unshared));
// 类
case TC_CLASS:
if (type == String.class) {throw new ClassCastException("Cannot cast a class to java.lang.String");
}
return readClass(unshared);
// 代理
case TC_CLASSDESC:
case TC_PROXYCLASSDESC:
if (type == String.class) {throw new ClassCastException("Cannot cast a class to java.lang.String");
}
return readClassDesc(unshared);
case TC_STRING:
case TC_LONGSTRING:
return checkResolve(readString(unshared));
// 数组
case TC_ARRAY:
if (type == String.class) {throw new ClassCastException("Cannot cast an array to java.lang.String");
}
return checkResolve(readArray(unshared));
// 枚举
case TC_ENUM:
if (type == String.class) {throw new ClassCastException("Cannot cast an enum to java.lang.String");
}
return checkResolve(readEnum(unshared));
// 对象
case TC_OBJECT:
if (type == String.class) {throw new ClassCastException("Cannot cast an object to java.lang.String");
}
return checkResolve(readOrdinaryObject(unshared));
// 异样
case TC_EXCEPTION:
if (type == String.class) {throw new ClassCastException("Cannot cast an exception to java.lang.String");
}
IOException ex = readFatalException();
throw new WriteAbortedException("writing aborted", ex);
case TC_BLOCKDATA:
case TC_BLOCKDATALONG:
if (oldMode) {bin.setBlockDataMode(true);
bin.peek(); // force header read
throw new OptionalDataException(bin.currentBlockRemaining());
} else {
throw new StreamCorruptedException("unexpected block data");
}
case TC_ENDBLOCKDATA:
if (oldMode) {throw new OptionalDataException(true);
} else {
throw new StreamCorruptedException("unexpected end of block data");
}
default:
throw new StreamCorruptedException(String.format("invalid type code: %02X", tc));
}
} finally {
depth--;
bin.setBlockDataMode(oldMode);
}
}能够看到解决对象的时候，调用了 readOrdinaryObject() 办法, 好家伙来了：
private Object readOrdinaryObject(boolean unshared)
throws IOException
{if (bin.readByte() != TC_OBJECT) {throw new InternalError();
}
ObjectStreamClass desc = readClassDesc(false);
desc.checkDeserialize();
Class<?> cl = desc.forClass();
if (cl == String.class || cl == Class.class
|| cl == ObjectStreamClass.class) {throw new InvalidClassException("invalid class descriptor");
}
Object obj;
try {
// 反射
obj = desc.isInstantiable() ? desc.newInstance() : null;
} catch (Exception ex) {throw (IOException) new InvalidClassException(desc.forClass().getName(),
"unable to create instance").initCause(ex);
}
passHandle = handles.assign(unshared ? unsharedMarker : obj);
ClassNotFoundException resolveEx = desc.getResolveException();
if (resolveEx != null) {handles.markException(passHandle, resolveEx);
}
if (desc.isExternalizable()) {readExternalData((Externalizable) obj, desc);
} else {readSerialData(obj, desc);
}
handles.finish(passHandle);
// 如果实现了 hasReadResolveMethod（）办法
if (obj != null &&
handles.lookupException(passHandle) == null &&
desc.hasReadResolveMethod())
{
// 执行 hasReadResolveMethod（）办法
Object rep = desc.invokeReadResolve(obj);
if (unshared && rep.getClass().isArray()) {rep = cloneArray(rep);
}
if (rep != obj) {
// Filter the replacement object
if (rep != null) {if (rep.getClass().isArray()) {filterCheck(rep.getClass(), Array.getLength(rep));
} else {filterCheck(rep.getClass(), -1);
}
}
handles.setObject(passHandle, obj = rep);
}
}
return obj;
}从下面的 diamante 能够看出，底层是通过反射来实现序列化的，那咱们如果不心愿它进行反射怎么办？而后能够看到反射之后，其实有一个查找 readResolveMethod() 办法无关，如果有实现readResolveMethod()，那就间接调用该办法返回后果，而不是返回反射调用之后的后果。这样尽管反射了，然而不起作用。
那要是咱们重写 readResolveMethod() 办法，就能够间接返回咱们的对象，而不是返回反射之后的对象了。
试试？
咱们将单例模式革新成为这样：
import java.io.Serializable;
public class Singleton implements Serializable,Cloneable {
private static int num = 0;
private volatile static Singleton singleton;
private Singleton() {synchronized (Singleton.class) {if (num == 0) {num++;} else {throw new RuntimeException("Don't use this method");
}
}
}
public static Singleton getSingleton() {if (singleton == null) {synchronized (Singleton.class) {if (singleton == null) {singleton = new Singleton();
}
}
}
return singleton;
}
@Override
protected Object clone() throws CloneNotSupportedException {return super.clone();
}
// 阻止反序列反射生成对象
private Object readResolve() {return singleton;}
}测试代码不变，后果如下，事实证明的确是这样，反序列化不会从新反射对象了，始终是同一个对象，问题完满解决了。
2055281021
20552810213. 小结
一个略微完满的单例，是不会让他人调用结构器的，然而 private 的结构器，并不能齐全阻止对单例的毁坏，如果应用反射还是能够非法调用到结构器，因为咱们须要一个次数，结构器如果调用次数过多，那么就间接报错。
然而有时候咱们心愿留个小后门，所以咱们大部分时候不能够毁坏单例模式。通过实现 cloneable 的形式，重写了 clone() 办法，就能够做到，生成不同的对象。
序列化和 clone()，有点像，都是被动提供毁坏的办法，然而很多时候不得已提供序列化接口，却不想被毁坏，这个时候能够通过重写readResolve() 办法，间接返回对象，不返回反射生成的对象，爱护了单例模式不被毁坏。