每日一问：你想如何破坏单例模式？
##前言vue
1.单例是什么？
单例模式：是一种建立型设计模式，目的是保证全局一个类只有一个实例对象，分为懒汉式和饿汉式。所谓懒汉式，相似于懒加载，须要的时候才会触发初始化实例对象。而饿汉式正好相反，项目启动，类加载的时候，就会建立初始化单例对象。java
1.1 优势
若是只有一个实例，那么就能够少占用系统资源，节省内存，访问也会相对较快。比较灵活。git
1.2 缺点
不能使用在变化的对象上，特别是不一样请求会形成不一样属性的对象。因为Spring自己默认实例就是单例的，因此使用的时候须要判断应用场景，要不会形成张冠李戴的现象。而每每操做引用和集合，就更不容易查找到这种诡异的问题。例如：一些配置获取，若是后期使用须要修改其值，要么定义使用单例，后期使用深拷贝，要么不要使用单例。github
既然使用单例模式，那么就得想尽一切办法，保证明例是惟一的，这也是单例模式的使命。可是代码是人写的，再完美的人也可能写出不那么完美的代码，再安全的系统，也有可能存在漏洞。既然你想保证单例，那我恰恰找出方法，建立同一个类多个不一样的对象呢？这就是对单例模式的破坏，到底有哪些方式能够破坏单例模式呢？主要可是不限于如下几种：设计模式
- 没有将构造器私有化，能够直接调用。
- 反射调用构造器
- 实现了
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());
}
复制代码
运行的结果以下：markdown
692404036
1554874502
1846274136
复制代码
三个对象的hashcode都不同，因此它们不是同一个对象，这样也就证实了，这种单例写法是不成功的。ide
2.2 反射调用构造器
若是单例类已经将构造方法声明成为private，那么暂时没法显式的调用到构造方法了，可是真的没有其余方法能够破坏单例了么？oop
答案是有！也就是经过反射调用构造方法，修改权限。
好比一个看似完美的单例模式：
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 more
复制代码
2.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
2055281021
复制代码
3. 小结
一个稍微完美的单例，是不会让别人调用构造器的，可是private的构造器，并不能彻底阻止对单例的破坏，若是使用反射仍是能够非法调用到构造器，由于咱们须要一个次数，构造器若是调用次数过多，那么就直接报错。
可是有时候咱们但愿留个小后门，因此咱们大部分时候不能够破坏单例模式。经过实现cloneable的方式，重写了clone()方法，就能够作到，生成不一样的对象。
序列化和clone()，有点像，都是主动提供破坏的方法，可是不少时候不得已提供序列化接口，却不想被破坏，这个时候能够经过重写readResolve()方法，直接返回对象，不返回反射生成的对象，保护了单例模式不被破坏。
主题列表：juejin, github, smartblue, cyanosis, channing-cyan, fancy, hydrogen, condensed-night-purple, greenwillow, v-green, vue-pro, healer-readable, mk-cute, jzman, geek-black, awesome-green
贡献主题：github.com/xitu/juejin…
theme: juejin highlight:
##前言
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 more
复制代码
2.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
2055281021
复制代码
3. 小结
一个稍微完美的单例，是不会让别人调用构造器的，可是private的构造器，并不能彻底阻止对单例的破坏，若是使用反射仍是能够非法调用到构造器，由于咱们须要一个次数，构造器若是调用次数过多，那么就直接报错。
可是有时候咱们但愿留个小后门，因此咱们大部分时候不能够破坏单例模式。经过实现cloneable的方式，重写了clone()方法，就能够作到，生成不一样的对象。
序列化和clone()，有点像，都是主动提供破坏的方法，可是不少时候不得已提供序列化接口，却不想被破坏，这个时候能够经过重写readResolve()方法，直接返回对象，不返回反射生成的对象，保护了单例模式不被破坏。
相关文章
- 1. 设计模式【1.1】-- 你想如何破坏单例模式？
- 2. 反射如何破坏单例模式
- 3. 教你破坏单例模式
- 4. 每日一模式之单例模式
- 5. java设计模式—单例模式（包含单例的破坏）
- 6. 反射对单例模式的破坏
- 7. 附：单例模式的破坏
- 8. 让咱们来破坏单例模式
- 9. 每日设计模式——单例模式
- 10. 【设计模式系列6】单例模式的8种写法及如何防止单例被破坏
- 更多相关文章...
- • XSD 如何使用? - XML Schema 教程
- • 如何伪造ARP响应？ - TCP/IP教程
- • 委托模式
- • 再有人问你分布式事务，把这篇扔给他
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. 设计模式【1.1】-- 你想如何破坏单例模式？
- 2. 反射如何破坏单例模式
- 3. 教你破坏单例模式
- 4. 每日一模式之单例模式
- 5. java设计模式—单例模式（包含单例的破坏）
- 6. 反射对单例模式的破坏
- 7. 附：单例模式的破坏
- 8. 让咱们来破坏单例模式
- 9. 每日设计模式——单例模式
- 10. 【设计模式系列6】单例模式的8种写法及如何防止单例被破坏