教你java面試時(shí)如何聊單例模式
NO.1 單例模式的應(yīng)用場(chǎng)景
單例模式（Singleton Pattern）是指確保一個(gè)類在任何情況下都絕對(duì)只有一個(gè)實(shí)例，并提供一個(gè)全局訪問(wèn)點(diǎn)。單例模式是創(chuàng)建型模式。單例模式在現(xiàn)實(shí)生活中應(yīng)用也非常廣泛。例如公司 CEO、部門經(jīng)理等。在 J2EE 標(biāo)準(zhǔn)中，ServletContext、ServletContextConfig 等；在 Spring 框架應(yīng)用中 ApplicationContext；數(shù)據(jù)庫(kù)的連接池也都是單例形式。
NO.2 餓漢式單例
先來(lái)看單例模式的類結(jié)構(gòu)圖：
餓漢式單例是在類加載的時(shí)候就立即初始化，并且創(chuàng)建單例對(duì)象。絕對(duì)線程安全，在線程還沒(méi)出現(xiàn)以前就是實(shí)例化了，不可能存在訪問(wèn)安全問(wèn)題。
優(yōu)點(diǎn)：沒(méi)有加任何的鎖、執(zhí)行效率比較高，在用戶體驗(yàn)上來(lái)說(shuō)，比懶漢式更好。
缺點(diǎn)：類加載的時(shí)候就初始化，不管用與不用都占著空間，浪費(fèi)了內(nèi)存，有可能占著茅坑不拉屎。
Spring 中 IOC 容器 ApplicationContext 本身就是典型的餓漢式單例。接下來(lái)看一段代碼：
public class HungrySingleton {
//先靜態(tài)、后動(dòng)態(tài)
//先屬性、后方法
//先上后下
private static final HungrySingleton hungrySingleton = new HungrySingleton();
private HungrySingleton(){}
public static HungrySingleton getInstance(){
return hungrySingleton;
}
}
還有另外一種寫法，利用靜態(tài)代碼塊的機(jī)制：
//餓漢式靜態(tài)塊單例
public class HungryStaticSingleton {
private static final HungryStaticSingleton hungrySingleton;
static {
hungrySingleton = new HungryStaticSingleton();
}
private HungryStaticSingleton(){}
public static HungryStaticSingleton getInstance(){
return hungrySingleton;
}
}
這兩種寫法都非常的簡(jiǎn)單，也非常好理解，餓漢式適用在單例對(duì)象較少的情況。下面我們來(lái)看性能更優(yōu)的寫法。
NO.3 懶漢式單例
懶漢式單例的特點(diǎn)是：被外部類調(diào)用的時(shí)候內(nèi)部類才會(huì)加載，下面看懶漢式單例的簡(jiǎn)單實(shí)現(xiàn) LazySimpleSingleton：
//懶漢式單例
//在外部需要使用的時(shí)候才進(jìn)行實(shí)例化
public class LazySimpleSingleton {
private LazySimpleSingleton(){}
//靜態(tài)塊，公共內(nèi)存區(qū)域
private static LazySimpleSingleton lazy = null;
public static LazySimpleSingleton getInstance(){
if(lazy == null){
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
然后寫一個(gè)線程類 ExectorThread 類：
public class ExectorThread implements Runnable{
@Override
public void run() {
LazySimpleSingleton singleton = LazySimpleSingleton.getInstance();
System.out.println(Thread.currentThread().getName() + ":" + singleton);
}
}
客戶端測(cè)試代碼：
public class LazySimpleSingletonTest {
public static void main(String[] args) {
Thread t1 = new Thread(new ExectorThread());
Thread t2 = new Thread(new ExectorThread());
t1.start();
t2.start();
System.out.println("End");
}
}
運(yùn)行結(jié)果：
一定幾率出現(xiàn)創(chuàng)建兩個(gè)不同結(jié)果的情況，意味著上面的單例存在線程安全隱患?，F(xiàn)在我們用調(diào)試運(yùn)行再具體看一下，教給大家一個(gè)新技能，用線程模式調(diào)試，手動(dòng)控制線程的執(zhí)行順序來(lái)跟蹤內(nèi)存的變化狀態(tài)。先給 ExectorThread 類打上斷點(diǎn)：
右鍵點(diǎn)擊斷點(diǎn)，切換為 Thread 模式，如下圖：
然后，給 LazySimpleSingleton 類打上斷點(diǎn)，同樣標(biāo)記為 Thread 模式：
切回到客戶端測(cè)試代碼，同樣也打上斷點(diǎn)，同時(shí)改為 Thread 模式，如下圖:
開(kāi)始 debug 之后，會(huì)看到 debug 控制臺(tái)可以自由切換 Thread 的運(yùn)行狀態(tài)：
通過(guò)不斷切換線程，并觀測(cè)其內(nèi)存狀態(tài)，我們發(fā)現(xiàn)在線程環(huán)境下 LazySimpleSingleton被實(shí)例化了兩次。有時(shí)，我們得到的運(yùn)行結(jié)果可能是相同的兩個(gè)對(duì)象，實(shí)際上是被后面執(zhí)行的線程覆蓋了，我們看到了一個(gè)假象，線程安全隱患依舊存在。那么，我們?nèi)绾蝸?lái)優(yōu)化代碼，使得懶漢式單例在線程環(huán)境下安全呢？來(lái)看下面的代碼，給 getInstance()加上 synchronized 關(guān)鍵字，是這個(gè)方法變成線程同步方法：
public class LazySimpleSingleton {
private LazySimpleSingleton(){}
//靜態(tài)塊，公共內(nèi)存區(qū)域
private static LazySimpleSingleton lazy = null;
public synchronized static LazySimpleSingleton getInstance(){
if(lazy == null){
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
這時(shí)候，我們?cè)賮?lái)調(diào)試。當(dāng)我們將其中一個(gè)線程執(zhí)行并調(diào)用 getInstance()方法時(shí)，另一個(gè)線程在調(diào)用 getInstance()方法，線程的狀態(tài)由 RUNNING 變成了 MONITOR,出現(xiàn)阻塞。直到第一個(gè)線程執(zhí)行完，第二個(gè)線程才恢復(fù) RUNNING 狀態(tài)繼續(xù)調(diào)用 getInstance()方法。如下圖所示：
完美的展現(xiàn)了 synchronized 監(jiān)視鎖的運(yùn)行狀態(tài)，線程安全的問(wèn)題便解決了。但是，用synchronized 加鎖，在線程數(shù)量比較多情況下，如果 CPU 分配壓力上升，會(huì)導(dǎo)致大批量線程出現(xiàn)阻塞，從而導(dǎo)致程序運(yùn)行性能大幅下降。那么，有沒(méi)有一種更好的方式，既兼顧線程安全又提升程序性能呢？答案是肯定的。我們來(lái)看雙重檢查鎖的單例模式：
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();
//1.分配內(nèi)存給這個(gè)對(duì)象
//2.初始化對(duì)象
//3.設(shè)置 lazy 指向剛分配的內(nèi)存地址 }
}
}
return lazy;
}
}
現(xiàn)在，我們來(lái)斷點(diǎn)調(diào)試：
當(dāng)?shù)谝粋€(gè)線程調(diào)用 getInstance()方法時(shí)，第二個(gè)線程也可以調(diào)用 getInstance()。當(dāng)?shù)谝粋€(gè)線程執(zhí)行到 synchronized 時(shí)會(huì)上鎖，第二個(gè)線程就會(huì)變成 MONITOR 狀態(tài)，出現(xiàn)阻
塞。此時(shí)，阻塞并不是基于整個(gè) LazySimpleSingleton 類的阻塞，而是在 getInstance()方法內(nèi)部阻塞，只要邏輯不是太復(fù)雜，對(duì)于調(diào)用者而言感知不到。但是，用到 synchronized 關(guān)鍵字，總歸是要上鎖，對(duì)程序性能還是存在一定影響的。難道就真的沒(méi)有更好的方案嗎？當(dāng)然是有的。我們可以從類初始化角度來(lái)考慮，看下面的代碼，采用靜態(tài)內(nèi)部類的方式：
//這種形式兼顧餓漢式的內(nèi)存浪費(fèi)，也兼顧synchronized性能問(wèn)題
//完美地屏蔽了這兩個(gè)缺點(diǎn)
public class LazyInnerClassSingleton {
//默認(rèn)使用LazyInnerClassGeneral的時(shí)候，會(huì)先初始化內(nèi)部類
//如果沒(méi)使用的話，內(nèi)部類是不加載的
private LazyInnerClassSingleton(){}
//每一個(gè)關(guān)鍵字都不是多余的
//static 是為了使單例的空間共享
//保證這個(gè)方法不會(huì)被重寫，重載
public static final LazyInnerClassSingleton getInstance(){
//在返回結(jié)果以前，一定會(huì)先加載內(nèi)部類
return LazyHolder.LAZY;
}
//默認(rèn)不加載
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
這種形式兼顧餓漢式的內(nèi)存浪費(fèi)，也兼顧 synchronized 性能問(wèn)題。內(nèi)部類一定是要在方
法調(diào)用之前初始化，巧妙地避免了線程安全問(wèn)題。由于這種方式比較簡(jiǎn)單，我們就不帶
大家一步一步調(diào)試了。
NO.4 反射破壞單例
大家有沒(méi)有發(fā)現(xiàn)，上面介紹的單例模式的構(gòu)造方法除了加上 private 以外，沒(méi)有做任何處理。如果我們使用反射來(lái)調(diào)用其構(gòu)造方法，然后，再調(diào)用 getInstance()方法，應(yīng)該就會(huì)兩個(gè)不同的實(shí)例。現(xiàn)在來(lái)看一段測(cè)試代碼，以 LazyInnerClassSingleton 為例：
public class LazyInnerClassSingletonTest {
public static void main(String[] args) {
try{
//很無(wú)聊的情況下，進(jìn)行破壞
Class<?> clazz = LazyInnerClassSingleton.class;
//通過(guò)反射拿到私有的構(gòu)造方法
Constructor c = clazz.getDeclaredConstructor(null);
//強(qiáng)制訪問(wèn)，強(qiáng)吻，不愿意也要吻
c.setAccessible(true);
//暴力初始化
Object o1 = c.newInstance();
//調(diào)用了兩次構(gòu)造方法，相當(dāng)于new了兩次
//犯了原則性問(wèn)題，
Object o2 = c.newInstance();
System.out.println(o1 == o2);
// Object o2 = c.newInstance();
}catch (Exception e){
e.printStackTrace();
}
}
}
運(yùn)行結(jié)果如下：
顯然，是創(chuàng)建了兩個(gè)不同的實(shí)例?，F(xiàn)在，我們?cè)谄錁?gòu)造方法中做一些限制，一旦出現(xiàn)多次重復(fù)創(chuàng)建，則直接拋出異常。來(lái)看優(yōu)化后的代碼：
碼：
//這種形式兼顧餓漢式的內(nèi)存浪費(fèi)，也兼顧synchronized性能問(wèn)題
//完美地屏蔽了這兩個(gè)缺點(diǎn)
//史上最牛B的單例模式的實(shí)現(xiàn)方式
public class LazyInnerClassSingleton {
//默認(rèn)使用LazyInnerClassGeneral的時(shí)候，會(huì)先初始化內(nèi)部類
//如果沒(méi)使用的話，內(nèi)部類是不加載的
private LazyInnerClassSingleton(){
if(LazyHolder.LAZY != null){
throw new RuntimeException("不允許創(chuàng)建多個(gè)實(shí)例");
}
}
//每一個(gè)關(guān)鍵字都不是多余的
//static 是為了使單例的空間共享
//保證這個(gè)方法不會(huì)被重寫，重載
public static final LazyInnerClassSingleton getInstance(){
//在返回結(jié)果以前，一定會(huì)先加載內(nèi)部類
return LazyHolder.LAZY;
}
//默認(rèn)不加載
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
再運(yùn)行測(cè)試代碼，會(huì)得到以下結(jié)果：
至此，史上最牛 B 的單例寫法便大功告成。
NO.5 序列化破壞單例
當(dāng)我們將一個(gè)單例對(duì)象創(chuàng)建好，有時(shí)候需要將對(duì)象序列化然后寫入到磁盤，下次使用時(shí)再?gòu)拇疟P中讀取到對(duì)象，反序列化轉(zhuǎn)化為內(nèi)存對(duì)象。反序列化后的對(duì)象會(huì)重新分配內(nèi)存，即重新創(chuàng)建。那如果序列化的目標(biāo)的對(duì)象為單例對(duì)象，就違背了單例模式的初衷，相當(dāng)于破壞了單例，來(lái)看一段代碼：
//反序列化時(shí)導(dǎo)致單例破壞
public class SeriableSingleton implements Serializable {
//序列化就是說(shuō)把內(nèi)存中的狀態(tài)通過(guò)轉(zhuǎn)換成字節(jié)碼的形式
//從而轉(zhuǎn)換一個(gè) IO 流，寫入到其他地方(可以是磁盤、網(wǎng)絡(luò) IO)
//內(nèi)存中狀態(tài)給永久保存下來(lái)了
//反序列化
//講已經(jīng)持久化的字節(jié)碼內(nèi)容，轉(zhuǎn)換為 IO 流
//通過(guò) IO 流的讀取，進(jìn)而將讀取的內(nèi)容轉(zhuǎn)換為 Java 對(duì)象
//在轉(zhuǎn)換過(guò)程中會(huì)重新創(chuàng)建對(duì)象 new
public final static SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton(){}
public static SeriableSingleton getInstance(){
return INSTANCE;
}
}
運(yùn)行結(jié)果：
運(yùn)行結(jié)果中，可以看出，反序列化后的對(duì)象和手動(dòng)創(chuàng)建的對(duì)象是不一致的，實(shí)例化了兩次，違背了單例的設(shè)計(jì)初衷。那么，我們?nèi)绾伪ＷC序列化的情況下也能夠?qū)崿F(xiàn)單例？其實(shí)很簡(jiǎn)單，只需要增加 readResolve()方法即可。來(lái)看優(yōu)化代碼：
public class SeriableSingleton implements Serializable {
//序列化就是說(shuō)把內(nèi)存中的狀態(tài)通過(guò)轉(zhuǎn)換成字節(jié)碼的形式
//從而轉(zhuǎn)換一個(gè)IO流，寫入到其他地方(可以是磁盤、網(wǎng)絡(luò)IO)
//內(nèi)存中狀態(tài)給永久保存下來(lái)了
//反序列化
//講已經(jīng)持久化的字節(jié)碼內(nèi)容，轉(zhuǎn)換為IO流
//通過(guò)IO流的讀取，進(jìn)而將讀取的內(nèi)容轉(zhuǎn)換為Java對(duì)象
//在轉(zhuǎn)換過(guò)程中會(huì)重新創(chuàng)建對(duì)象new
public final static SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton(){}
public static SeriableSingleton getInstance(){
return INSTANCE;
}
private Object readResolve(){
return INSTANCE;
}
}
再看運(yùn)行結(jié)果：
大家一定會(huì)關(guān)心這是什么原因呢？為什么要這樣寫？看上去很神奇的樣子，也讓人有些費(fèi) 解 。不 如 ， 我 們 一 起 來(lái) 看 看 JDK 的 源 碼 實(shí) 現(xiàn) 以 一 清 二 楚 了 。我 們 進(jìn) 入ObjectInputStream 類的 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();
}
}
}
我們發(fā)現(xiàn)在readObject中又調(diào)用了我們重寫的readObject0()方法。進(jìn)入readObject0()方法，代碼如下：
private Object readObject0(boolean unshared) throws IOException {
...
case TC_OBJECT:
return checkResolve(readOrdinaryObject(unshared));
...
}
我們看到 TC_OBJECTD 中判斷，調(diào)用了 ObjectInputStream 的 readOrdinaryObject()方法，我們繼續(xù)進(jìn)入看源碼：
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);
}
...
return obj;
}
發(fā)現(xiàn)調(diào)用了 ObjectStreamClass 的 isInstantiable()方法，而 isInstantiable()里面的代碼如下：
boolean isInstantiable() {
requireInitialized();
return (cons != null);
}
代碼非常簡(jiǎn)單，就是判斷一下構(gòu)造方法是否為空，構(gòu)造方法不為空就返回 true。意味著，只要有無(wú)參構(gòu)造方法就會(huì)實(shí)例化。這時(shí)候，其實(shí)還沒(méi)有找到為什么加上 readResolve()方法就避免了單例被破壞的真正原因。我再回到ObjectInputStream 的 readOrdinaryObject()方法繼續(xù)往下看：
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);
}
...
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;
}
判斷無(wú)參構(gòu)造方法是否存在之后，又調(diào)用了 hasReadResolveMethod()方法，來(lái)看代碼：
boolean hasReadResolveMethod() {
requireInitialized();
return (readResolveMethod != null);
}
邏輯非常簡(jiǎn)單，就是判斷 readResolveMethod 是否為空，不為空就返回 true。那么readResolveMethod 是在哪里賦值的呢？通過(guò)全局查找找到了賦值代碼在私有方法ObjectStreamClass()方法中給 readResolveMethod 進(jìn)行賦值，來(lái)看代碼：
readResolveMethod = getInheritableMethod(
cl, "readResolve", null, Object.class);
上面的邏輯其實(shí)就是通過(guò)反射找到一個(gè)無(wú)參的 readResolve()方法，并且保存下來(lái)?，F(xiàn)在
再 回 到 ObjectInputStream的 readOrdinaryObject() 方 法 繼 續(xù) 往 下 看 ， 如 果
readResolve()存在則調(diào)用 invokeReadResolve()方法，來(lái)看代碼：
Object invokeReadResolve(Object obj)
throws IOException, UnsupportedOperationException
{
requireInitialized();
if (readResolveMethod != null) {
try {
return readResolveMethod.invoke(obj, (Object[]) null);
} catch (InvocationTargetException ex) {
Throwable th = ex.getTargetException();
if (th instanceof ObjectStreamException) {
throw (ObjectStreamException) th;
} else {
throwMiscException(th);
throw new InternalError(th); // never reached
}
} catch (IllegalAccessException ex) {
// should not occur, as access checks have been suppressed
throw new InternalError(ex);
}
} else {
throw new UnsupportedOperationException();
}
}
我們可以看到在invokeReadResolve()方法中用反射調(diào)用了readResolveMethod方法。通過(guò) JDK 源碼分析我們可以看出，雖然，增加 readResolve()方法返回實(shí)例，解決了單例被破壞的問(wèn)題。但是，我們通過(guò)分析源碼以及調(diào)試，我們可以看到實(shí)際上實(shí)例化了兩次，只不過(guò)新創(chuàng)建的對(duì)象沒(méi)有被返回而已。那如果，創(chuàng)建對(duì)象的動(dòng)作發(fā)生頻率增大，就意味著內(nèi)存分配開(kāi)銷也就隨之增大，難道真的就沒(méi)辦法從根本上解決問(wèn)題嗎？下面我們來(lái)注冊(cè)式單例也許能幫助到你
NO.6 注冊(cè)式單例
注冊(cè)式單例又稱為登記式單例，就是將每一個(gè)實(shí)例都登記到某一個(gè)地方，使用唯一的標(biāo)識(shí)獲取實(shí)例。注冊(cè)式單例有兩種寫法：一種為容器緩存，一種為枚舉登記。先來(lái)看枚舉式單例的寫法，來(lái)看代碼，創(chuàng)建 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;
}
}
來(lái)看測(cè)試代碼：
public class EnumSingletonTest {
public static void main(String[] args) {
try {
EnumSingleton instance1 = null;
EnumSingleton instance2 = EnumSingleton.getInstance();
instance2.setData(new Object());
FileOutputStream fos = new FileOutputStream("EnumSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(instance2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("EnumSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
instance1 = (EnumSingleton) ois.readObject();
ois.close();
System.out.println(instance1.getData());
System.out.println(instance2.getData());
System.out.println(instance1.getData() == instance2.getData());
}catch (Exception e){
e.printStackTrace();
}
}
}
運(yùn)行結(jié)果：
沒(méi)有做任何處理，我們發(fā)現(xiàn)運(yùn)行結(jié)果和我們預(yù)期的一樣。那么枚舉式單例如此神奇，的神秘之處在哪里體現(xiàn)呢？下面我們通過(guò)分析源碼來(lái)揭開(kāi)它的神秘面紗。下載一個(gè)非常好用的 Java 反編譯工具 Jad（下載地址：https://varaneckas.com/jad/），解壓后配置好環(huán)境變量（這里不做詳細(xì)介紹），就可以使用命令行調(diào)用了。找到工程所在的 class 目錄，復(fù)制 EnumSingleton.class 所在的路徑，如下圖：
然后切回到命令行，切換到工程所在的 Class 目錄，輸入命令 jad 后面輸入復(fù)制好的路徑，我們會(huì)在 Class 目錄下會(huì)多一個(gè) EnumSingleton.jad 文件。打開(kāi) EnumSingleton.jad文件我們驚奇又巧妙地發(fā)現(xiàn)有如下代碼：
static
{
INSTANCE = new EnumSingleton("INSTANCE", 0);
$VALUES = (new EnumSingleton[] {
INSTANCE
});
}
原來(lái)，枚舉式單例在靜態(tài)代碼塊中就給 INSTANCE 進(jìn)行了賦值，是餓漢式單例的實(shí)現(xiàn)。至此，我們還可以試想，序列化我們能否破壞枚舉式單例呢？我們不妨再來(lái)看一下 JDK源碼，還是回到 ObjectInputStream 的 readObject0()方法：
private Object readObject0(boolean unshared) throws IOException {
...
case TC_ENUM:
return checkResolve(readEnum(unshared));
...
}
我們看到在 readObject0()中調(diào)用了 readEnum()方法，來(lái)看 readEnum()中代碼實(shí)現(xiàn)：
private Enum<?> readEnum(boolean unshared) throws IOException {
if (bin.readByte() != TC_ENUM) {
throw new InternalError();
}
ObjectStreamClass desc = readClassDesc(false);
if (!desc.isEnum()) {
throw new InvalidClassException("non-enum class: " + desc);
}
int enumHandle = handles.assign(unshared ? unsharedMarker : null);
ClassNotFoundException resolveEx = desc.getResolveException();
if (resolveEx != null) {
handles.markException(enumHandle, resolveEx);
}
String name = readString(false);
Enum<?> result = null;
Class<?> cl = desc.forClass();
if (cl != null) {
try {
@SuppressWarnings("unchecked")
Enum<?> en = Enum.valueOf((Class)cl, name);
result = en;
} catch (IllegalArgumentException ex) {
throw (IOException) new InvalidObjectException(
"enum constant " + name + " does not exist in " +
cl).initCause(ex);
}
if (!unshared) {
handles.setObject(enumHandle, result);
}
}
handles.finish(enumHandle);
passHandle = enumHandle;
return result;
}
我們發(fā)現(xiàn)枚舉類型其實(shí)通過(guò)類名和 Class 對(duì)象類找到一個(gè)唯一的枚舉對(duì)象。因此，枚舉對(duì)象不可能被類加載器加載多次。那么反射是否能破壞枚舉式單例呢？來(lái)看一段測(cè) 試代碼：
public static void main(String[] args) {
try {
Class clazz = EnumSingleton.class;
Constructor c = clazz.getDeclaredConstructor();
c.newInstance();
}catch (Exception e){
e.printStackTrace();
}
}
運(yùn)行結(jié)果：
報(bào)的是 java.lang.NoSuchMethodException 異常，意思是沒(méi)找到無(wú)參的構(gòu)造方法。這時(shí)候，我們打開(kāi) java.lang.Enum 的源碼代碼，查看它的構(gòu)造方法，只有一個(gè) protected的構(gòu)造方法，代碼如下：
protected Enum(String name, int ordinal) {
this.name = name;
this.ordinal = ordinal;
}
那我們?cè)賮?lái)做一個(gè)這樣的測(cè)試：
public static void main(String[] args) {
try {
Class clazz = EnumSingleton.class;
Constructor c = clazz.getDeclaredConstructor(String.class,int.class);
c.setAccessible(true);
EnumSingleton enumSingleton = (EnumSingleton)c.newInstance("Tom",666);
}catch (Exception e){
e.printStackTrace();
}
}
運(yùn)行結(jié)果：
這時(shí)錯(cuò)誤已經(jīng)非常明顯了，告訴我們 Cannot reflectively create enum objects，不能用反射來(lái)創(chuàng)建枚舉類型。還是習(xí)慣性地想來(lái)看看 JDK 源碼，進(jìn)入 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;
}
在 newInstance()方法中做了強(qiáng)制性的判斷，如果修飾符是 Modifier.ENUM 枚舉類型，直接拋出異常。到這為止，我們是不是已經(jīng)非常清晰明了呢？枚舉式單例也是《EffectiveJava》書中推薦的一種單例實(shí)現(xiàn)寫法。在 JDK 枚舉的語(yǔ)法特殊性，以及反射也為枚舉保駕護(hù)航，讓枚舉式單例成為一種比較優(yōu)雅的實(shí)現(xiàn)。
接下來(lái)看注冊(cè)式單例還有另一種寫法，容器緩存的寫法，創(chuàng)建 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);
}
}
}
}
容器式寫法適用于創(chuàng)建實(shí)例非常多的情況，便于管理。但是，是非線程安全的。到此，注冊(cè)式單例介紹完畢。我們還可以來(lái)看看 Spring 中的容器式單例的實(shí)現(xiàn)代碼：
public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory
implements AutowireCapableBeanFactory {
/** Cache of unfinished FactoryBean instances: FactoryBean name --> BeanWrapper */
private final Map<String, BeanWrapper> factoryBeanInstanceCache = new ConcurrentHashMap<>(16);
...
}
NO.7 ThreadLocal 線程單例
最后給大家贈(zèng)送一個(gè)彩蛋，講講線程單例實(shí)現(xiàn) ThreadLocal。ThreadLocal 不能保證其創(chuàng)建的對(duì)象是全局唯一，但是能保證在單個(gè)線程中是唯一的，天生的線程安全。下面我們來(lái)看代碼：
public class ThreadLocalSingleton {
private static final ThreadLocal<ThreadLocalSingleton> threadLocalInstance =
new ThreadLocal<ThreadLocalSingleton>(){
@Override
protected ThreadLocalSingleton initialValue() {
return new ThreadLocalSingleton();
}
};
private ThreadLocalSingleton(){}
public static ThreadLocalSingleton getInstance(){
return threadLocalInstance.get();
}
}
寫一下測(cè)試代碼：
public static void main(String[] args) {
System.out.println(ThreadLocalSingleton.getInstance());
System.out.println(ThreadLocalSingleton.getInstance());
System.out.println(ThreadLocalSingleton.getInstance());
System.out.println(ThreadLocalSingleton.getInstance());
System.out.println(ThreadLocalSingleton.getInstance());
Thread t1 = new Thread(new ExectorThread());
Thread t2 = new Thread(new ExectorThread());
t1.start();
t2.start();
System.out.println("End");
}
運(yùn)行結(jié)果：
我們發(fā)現(xiàn)，在主線程 main 中無(wú)論調(diào)用多少次，獲取到的實(shí)例都是同一個(gè)，都在兩個(gè)子線程中分別獲取到了不同的實(shí)例。那么 ThreadLocal 是如果實(shí)現(xiàn)這樣的效果的呢？我們知道上面的單例模式為了達(dá)到線程安全的目的，給方法上鎖，以時(shí)間換空間。ThreadLocal將所有的對(duì)象全部放在 ThreadLocalMap 中，為每個(gè)線程都提供一個(gè)對(duì)象，實(shí)際上是以空間換時(shí)間來(lái)實(shí)現(xiàn)線程間隔離的。
總結(jié)
單例模式可以保證內(nèi)存里只有一個(gè)實(shí)例，減少了內(nèi)存開(kāi)銷；可以避免對(duì)資源的多重占用。單例模式看起來(lái)非常簡(jiǎn)單，實(shí)現(xiàn)起來(lái)其實(shí)也非常簡(jiǎn)單。但是在面試中卻是一個(gè)高頻面試題。希望小伙伴們通過(guò)本章的學(xué)習(xí)，可以對(duì)您有所幫助，希望您可以多多關(guān)注腳本之家的更多內(nèi)容！
相關(guān)文章
這篇文章主要給大家介紹了關(guān)于JDK8升級(jí)JDK17過(guò)程中踩到的一些坑,對(duì)于一些老的項(xiàng)目,升級(jí)到JDK8則存在一些兼容性問(wèn)題,是否升級(jí)需要酌情考慮,需要的朋友可以參考下2023-07-07
本篇是Hadoop源碼分析系列文章第三篇，主要介紹Hadoop啟動(dòng)以及腳本的剖析，后續(xù)本系列文章會(huì)持續(xù)更新，有需要的朋友可以借鑒參考下2021-09-09
這篇文章主要介紹了Spring整合Mybatis的全過(guò)程，包括spring配置文件書寫映射器接口的實(shí)例代碼，本文給大家介紹的非常詳細(xì),需要的朋友可以參考下2021-06-06
這篇文章主要介紹了Java中的序列化機(jī)制詳細(xì)解讀,序列化：將對(duì)象的狀態(tài)信息轉(zhuǎn)換為可以存儲(chǔ)或傳輸?shù)臄?shù)據(jù)形式(比如二進(jìn)制)的過(guò)程,反序列化：與序列化相對(duì),把序列化轉(zhuǎn)換成的可以存儲(chǔ)或傳輸?shù)臄?shù)據(jù)形式轉(zhuǎn)化為對(duì)象的狀態(tài)信息的過(guò)程,需要的朋友可以參考下2023-11-11
Java中遍歷集合的并發(fā)修改異常解決方案實(shí)例代碼
當(dāng)你遍歷集合的同時(shí),又往集合中添加或者刪除元素,就可能報(bào)并發(fā)修改異常,下面這篇文章主要給大家介紹了關(guān)于Java中遍歷集合的并發(fā)修改異常解決方案的相關(guān)資料,需要的朋友可以參考下2022-12-12
在java中提供有對(duì)于文件操作系統(tǒng)的支持,這個(gè)支持在java.io.File類中進(jìn)行了定義,也就是說(shuō)在整個(gè)java.io包中File類是唯一一個(gè)與文件本身操作有關(guān)的類(創(chuàng)建,刪除,重命名)有關(guān)的類,而如果想要進(jìn)行File類的操作,我們需要提供有完整的路徑支持,而后可以調(diào)用相應(yīng)的方法進(jìn)行處理2022-09-09
這篇文章主要介紹了Java常用對(duì)象操作工具代碼實(shí)例,文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-12-12
這篇文章主要介紹了springboot獲取profile的操作，文中的示例代碼講解詳細(xì)，具有很好的參考價(jià)值，希望對(duì)大家有所幫助2022-04-04
如何解決Spring事務(wù)注解@Transactional在類內(nèi)部方法調(diào)用不生效
這篇文章主要介紹了如何解決Spring事務(wù)注解@Transactional在類內(nèi)部方法調(diào)用不生效問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-08-08
JAVA實(shí)現(xiàn)利用第三方平臺(tái)發(fā)送短信驗(yàn)證碼
本文以注冊(cè)為例，在SpringMVC+Spring+Mybatis框架的基礎(chǔ)上完成該短信驗(yàn)證碼功能。需要的朋友一起來(lái)看下吧2016-12-12