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