單例設計模式
單例設計模式的核心思想是，程序運行中只允許某個類只有一個實例
序列化破壞單例模式
首先寫一個單例的類
public class Student implements Serializable {
private static Student student;
private Student() {
}
public static Student get() {
if (student == null) {
synchronized (Student.class) {
if (student == null) {
student = new Student();
}
}
}
return student;
}
}
測試Student是否爲單例
public static void main(String[] args) throws Exception {
Student oldStudent = Student.get();
System.out.println("序列化之前：" + (oldStudent == Student.get()));
}
輸出結果爲true，說明通過get()方法獲取到的兩個Student對象是同一對象，該類確實是單例。
序列化進行測試
public static void main(String[] args) throws Exception {
ObjectOutputStream objectOutputStream = new ObjectOutputStream(new FileOutputStream("tempFile"));
objectOutputStream.writeObject(Student.get());
ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream(new File("tempFile")));
Student student = (Student) objectInputStream.readObject();
System.out.println("序列化之後：" + (student == Student.get()));
}
輸出結果爲false。
既然單例模式只允許該類只能有一個實例，那麼爲什麼兩個Student對象不是同一個對象？讓我們再深入分析一下
對象的序列化過程通過ObjectOutputStream和ObjectInputputStream來實現的，那麼帶着剛剛的問題，分析一下ObjectInputputStream 的readObject方法執行情況到底是怎樣的
readObject源碼
public final Object readObject()
throws IOException, ClassNotFoundException
{
if (enableOverride) {
return readObjectOverride();
}
// if nested read, passHandle contains handle of enclosing object
int outerHandle = passHandle;
try {
Object obj = readObject0(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(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) {
case TC_NULL:
return readNull();
case TC_REFERENCE:
return readHandle(unshared);
case TC_CLASS:
return readClass(unshared);
case TC_CLASSDESC:
case TC_PROXYCLASSDESC:
return readClassDesc(unshared);
case TC_STRING:
case TC_LONGSTRING:
return checkResolve(readString(unshared));
case TC_ARRAY:
return checkResolve(readArray(unshared));
case TC_ENUM:
return checkResolve(readEnum(unshared));
case TC_OBJECT:
return checkResolve(readOrdinaryObject(unshared));
case TC_EXCEPTION:
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);
}
}
最下面，讀取並返回對象的邏輯是在 TC_OBJECT的case中，也就是調用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);
if (obj != null &&
handles.lookupException(passHandle) == null &&
desc.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;
}
直接定位到核心代碼
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);
}
isInstantiable：如果一個類可以在運行時實例化，就返回true
newInstance：使用反射調用無參構造創建一個對象。
現在已經很明確了，readObject方法是在運行時調用無參構造方法重新創建了對象。即使是私有的方法也可以通過反射去調用，因此私有構造並不能防止用戶去創建第二個該類的實例
那麼應該如何防止單例模式被破壞呢，只需要在Student類裏編寫一個readResolve方法
private Object readResolve() {
return student;
}
我們回到此前的代碼，繼續閱讀readOrdinaryObject
if (obj != null &&
handles.lookupException(passHandle) == null &&
desc.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);
}
}
hasReadResolveMethod：如果實現了序列化的類中包含readResolve方法就返回true
invokeReadResolve：通過反射調用readResolve方法
至此，原理很清楚了，只需要在類中編寫一個readResolve方法，就可以防止在序列化過程中破壞單例模式