單例模式
單例模式（Singleton Pattern）是指確保一個類在任何情況下都絕對只有一個實例，并提供一個全局訪問點。單例模式是創(chuàng)建型模式。單例模式在現(xiàn)實生活中應用也非常廣泛。例如，國家主席、公司 CEO、部門經(jīng)理等。在 J2EE 標準中，ServletContext、ServletContextConfig等；在Spring框架應用中ApplicationContext；數(shù)據(jù)庫的連接池也都是單例形式。
單利模式的幾種形式
餓漢式單例
餓漢式單例是在類加載的時候就立即初始化，并且創(chuàng)建單例對象。絕對線程安全，在線程還沒出現(xiàn)以前就是實例化了，不可能存在訪問安全問題。
優(yōu)點：沒有加任何的鎖、執(zhí)行效率比較高，在用戶體驗上來說，比懶漢式更好。
缺點：類加載的時候就初始化，不管用與不用都占著空間，浪費了內(nèi)存，有可能占著茅坑不拉屎。
Spring中IOC容器ApplicationContext本身就是典型的餓漢式單例。接下來看一段代碼。
public class HungrySingleton {
private static final HungrySingleton hungrySingleton = new HungrySingleton();
private HungrySingleton(){}
public static HungrySingleton getInstance(){
return hungrySingleton;
}
}
還有另外一種寫法，利用靜態(tài)代碼塊的機制：
public class HungryStaticSingleton {
private static final HungryStaticSingleton hungrySingleton;
static {
hungrySingleton = new HungryStaticSingleton();
}
private HungryStaticSingleton(){}
public static HungryStaticSingleton getInstance(){
return hungrySingleton;
}
}
這兩種寫法都非常的簡單，也非常好理解，餓漢式適用在單例對象較少的情況,下面我們來看性能更優(yōu)的寫法。
懶漢式單例
懶漢式單例的特點是：被外部類調(diào)用的時候內(nèi)部類才會加載，下面看懶漢式單例的簡單實現(xiàn)LazySimpleSingleton：
//懶漢式單例
//在外部需要使用的時候才進行實例化
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;
}
}
然后寫一個線程類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");
}
}
運行結果：
Thread-1:com.pattern.singleton.lazy.LazySimpleSingleton@298c37fd
Thread-0:com.pattern.singleton.lazy.LazySimpleSingleton@607bff5a
一定幾率出現(xiàn)創(chuàng)建兩個不同結果的情況，意味著上面的單例存在線程安全隱患。現(xiàn)在我們用調(diào)試運行再具體看一下，教給大家一個新技能，用線程模式調(diào)試，手動控制線程的執(zhí)行順序來跟蹤內(nèi)存的變化狀態(tài)。先給ExectorThread類打上斷點：
右鍵點擊斷點，切換為Thread模式，如下圖：
然后，給LazySimpleSingleton類打上斷點，同樣標記為Thread模式：
切回到客戶端測試代碼，同樣也打上斷點，同時改為Thread模式，如下圖:
開始debug之后，會看到debug控制臺可以自由切換Thread的運行狀態(tài)：
通過不斷切換線程，并觀測其內(nèi)存狀態(tài)，我們發(fā)現(xiàn)在線程環(huán)境下LazySimpleSingleton被實例化了兩次。有時，我們得到的運行結果可能是相同的兩個對象，實際上是被后面執(zhí)行的線程覆蓋了，我們看到了一個假象，線程安全隱患依舊存在。那么，我們?nèi)绾蝸韮?yōu)化代碼，使得懶漢式單例在線程環(huán)境下安全呢？來看下面的代碼，給getInstance()加上synchronized關鍵字，是這個方法變成線程同步方法：
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;
}
}
這時候，我們再來調(diào)試。當我們將其中一個線程執(zhí)行并調(diào)用getInstance()方法時，另一個線程在調(diào)用 getInstance()方法，線程的狀態(tài)由RUNNING 變成了MONITOR,出現(xiàn)阻塞。直到第一個線程執(zhí)行完，第二個線程才恢復RUNNING狀態(tài)繼續(xù)調(diào)用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.分配內(nèi)存給這個對象
//2.初始化對象
//3.設置lazy指向剛分配的內(nèi)存地址
//4.初次訪問對象
}
}
}
return lazy;
}
}
現(xiàn)在，我們來斷點調(diào)試：
調(diào)試如下：
當?shù)谝粋€線程調(diào)用getInstance()方法時，第二個線程也可以調(diào)用getInstance()。當?shù)谝粋€線程執(zhí)行到synchronized時會上鎖，第二個線程就會變成MONITOR 狀態(tài)，出現(xiàn)阻塞。此時，阻塞并不是基于整個LazySimpleSingleton類的阻塞，而是在getInstance()方法內(nèi)部阻塞，只要邏輯不是太復雜，對于調(diào)用者而言感知不到。但是，用到synchronized關鍵字，總歸是要上鎖，對程序性能還是存在一定影響的。難道就真的沒有更好的方案嗎？
當然是有的。我們可以從類初始化角度來考慮，看下面的代碼，采用靜態(tài)內(nèi)部類的方式：
//這種形式兼顧餓漢式的內(nèi)存浪費，也兼顧synchronized性能問題
//完美地屏蔽了這兩個缺點
//史上最牛B的單例模式的實現(xiàn)方式
public class LazyInnerClassSingleton {
//默認使用LazyInnerClassGeneral的時候，會先初始化內(nèi)部類
//如果沒使用的話，內(nèi)部類是不加載的
private LazyInnerClassSingleton(){
}
//每一個關鍵字都不是多余的
//static 是為了使單例的空間共享
//final 保證這個方法不會被重寫，重載
public static final LazyInnerClassSingleton getInstance(){
//在返回結果以前，一定會先加載內(nèi)部類
return LazyHolder.LAZY;
}
//默認不加載
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
這種形式兼顧餓漢式的內(nèi)存浪費，也兼顧synchronized性能問題。內(nèi)部類一定是要在方法調(diào)用之前初始化，巧妙地避免了線程安全問題。由于這種方式比較簡單，
反射破壞單例
大家有沒有發(fā)現(xiàn)，上面介紹的單例模式的構造方法除了加上private以外，沒有做任何處理。如果我們使用反射來調(diào)用其構造方法，然后，再調(diào)用getInstance()方法，應該就會兩個不同的實例?，F(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();
//調(diào)用了兩次構造方法，相當于new了兩次
//犯了原則性問題，
Object o2 = c.newInstance();
System.out.println(o1 == o2);
}catch (Exception e){
e.printStackTrace();
}
}
}
運行結果如下：
顯然，是創(chuàng)建了兩個不同的實例?，F(xiàn)在，我們在其構造方法中做一些限制，一旦出現(xiàn)多次重復創(chuàng)建，則直接拋出異常。來看優(yōu)化后的代碼：
//這種形式兼顧餓漢式的內(nèi)存浪費，也兼顧synchronized性能問題
//完美地屏蔽了這兩個缺點
//史上最牛B的單例模式的實現(xiàn)方式
public class LazyInnerClassSingleton {
//默認使用LazyInnerClassGeneral的時候，會先初始化內(nèi)部類
//如果沒使用的話，內(nèi)部類是不加載的
private LazyInnerClassSingleton(){
if(LazyHolder.LAZY != null){
throw new RuntimeException("不允許創(chuàng)建多個實例");
}
}
//每一個關鍵字都不是多余的
//static 是為了使單例的空間共享
//保證這個方法不會被重寫，重載
public static final LazyInnerClassSingleton getInstance(){
//在返回結果以前，一定會先加載內(nèi)部類
return LazyHolder.LAZY;
}
//默認不加載
private static class LazyHolder{
private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
}
}
再運行測試代碼，會得到以下結果：
至此，史上最牛B的單例寫法便大功告成。
序列化破壞單例
當我們將一個單例對象創(chuàng)建好，有時候需要將對象序列化然后寫入到磁盤，下次使用時再從磁盤中讀取到對象，反序列化轉化為內(nèi)存對象。反序列化后的對象會重新分配內(nèi)存，即重新創(chuàng)建。那如果序列化的目標的對象為單例對象，就違背了單例模式的初衷，相當于破壞了單例，來看一段代碼：
//反序列化時導致單例破壞
public class SeriableSingleton implements Serializable {
//序列化就是說把內(nèi)存中的狀態(tài)通過轉換成字節(jié)碼的形式
//從而轉換一個IO流，寫入到其他地方(可以是磁盤、網(wǎng)絡IO)
//內(nèi)存中狀態(tài)給永久保存下來了
//反序列化
//講已經(jīng)持久化的字節(jié)碼內(nèi)容，轉換為IO流
//通過IO流的讀取，進而將讀取的內(nèi)容轉換為Java對象
//在轉換過程中會重新創(chuàng)建對象new
public final static SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton(){}
public static SeriableSingleton getInstance(){
return INSTANCE;
}
}
編寫測試代碼：
public class SeriableSingletonTest {
public static void main(String[] args) {
SeriableSingleton s1 = null;
SeriableSingleton s2 = SeriableSingleton.getInstance();
FileOutputStream fos = null;
try {
fos = new FileOutputStream("SeriableSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
s1 = (SeriableSingleton)ois.readObject();
ois.close();
System.out.println(s1);
System.out.println(s2);
System.out.println(s1 == s2);
} catch (Exception e) {
e.printStackTrace();
}
}
}
運行結果：
com.pattern.singleton.seriable.SeriableSingleton@568db2f2
com.pattern.singleton.seriable.SeriableSingleton@7f31245a
false
Process finished with exit code 0
運行結果中，可以看出，反序列化后的對象和手動創(chuàng)建的對象是不一致的，實例化了兩次，違背了單例的設計初衷。那么，我們?nèi)绾伪ＷC序列化的情況下也能夠實現(xiàn)單例？其實很簡單，只需要增加readResolve()方法即可。來看優(yōu)化代碼：
//反序列化時導致單例破壞
public class SeriableSingleton implements Serializable {
//序列化就是說把內(nèi)存中的狀態(tài)通過轉換成字節(jié)碼的形式
//從而轉換一個IO流，寫入到其他地方(可以是磁盤、網(wǎng)絡IO)
//內(nèi)存中狀態(tài)給永久保存下來了
//反序列化
//講已經(jīng)持久化的字節(jié)碼內(nèi)容，轉換為IO流
//通過IO流的讀取，進而將讀取的內(nèi)容轉換為Java對象
//在轉換過程中會重新創(chuàng)建對象new
public final static SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton(){}
public static SeriableSingleton getInstance(){
return INSTANCE;
}
private Object readResolve(){
return INSTANCE;
}
}
再看運行結果：
com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@7f31245a
com.gupaoedu.vip.pattern.singleton.seriable.SeriableSingleton@7f31245a
true
Process finished with exit code 0
大家一定會關心這是什么原因呢？為什么要這樣寫？看上去很神奇的樣子，也讓人有些費解。不如，我們一起來看看 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中又調(diào)用了我們重寫的readObject0()方法。進入readObject0()方法，代碼如下：
private Object readObject0(boolean unshared) throws IOException {
....
case TC_OBJECT:
return checkResolve(readOrdinaryObject(unshared));
....
}
我們看到TC_OBJECTD中判斷，調(diào)用了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)調(diào)用了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);
}
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;
}
判斷無參構造方法是否存在之后，又調(diào)用了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()存在則調(diào)用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()方法中用反射調(diào)用了readResolveMethod方法。通過JDK 源碼分析我們可以看出，雖然，增加readResolve()方法返回實例，解決了單例被破壞的問題。但是，我們通過分析源碼以及調(diào)試，我們可以看到實際上實例化了兩次，只不過新創(chuàng)建的對象沒有被返回而已。那如果，創(chuàng)建對象的動作發(fā)生頻率增大，就意味著內(nèi)存分配開銷也就隨之增大，難道真的就沒辦法從根本上解決問題嗎？
下面我們來注冊式單例也許能幫助到你。
注冊式單例
注冊式單例又稱為登記式單例，就是將每一個實例都登記到某一個地方，使用唯一的標識獲取實例。注冊式單例有兩種寫法：一種為容器緩存，一種為枚舉登記。先來看枚舉式單例的寫法，來看代碼，創(chuàng)建EnumSingleton類：
//常量中去使用，常量不就是用來大家都能夠共用嗎？
//通常在通用API中使用
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();
}
}
}
運行結果：
java.lang.Object@378bf509
java.lang.Object@378bf509
true
Process finished with exit code 0
沒有做任何處理，我們發(fā)現(xiàn)運行結果和我們預期的一樣。那么枚舉式單例如此神奇，它的神秘之處在哪里體現(xiàn)呢？下面我們通過分析源碼來揭開它的神秘面紗。
下載一個非常好用的Java反編譯工具Jad（下載地址：https://varaneckas.com/jad/），解壓后配置好環(huán)境變量（這里不做詳細介紹），就可以使用命令行調(diào)用了。找到工程所在的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 {
....
depth++;
totalObjectRefs++;
try {
switch (tc) {
case TC_NULL:
return readNull();
case TC_ENUM:
return checkResolve(readEnum(unshared));
......
}
} finally {
depth--;
bin.setBlockDataMode(oldMode);
}
}
我們看到在readObject0()中調(diào)用了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: com.gupaoedu.vip.pattern.singleton.register.EnumSingleton.<init>()
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.getDeclaredConstructor(Class.java:2178)
at com.gupaoedu.vip.pattern.singleton.test.EnumSingletonTest.main(EnumSingletonTest.java:57)
Process finished with exit code 0
報的是 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();
}
}
運行結果：
java.lang.IllegalArgumentException: Cannot reflectively create enum objects
at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
at com.gupaoedu.vip.pattern.singleton.test.EnumSingletonTest.main(EnumSingletonTest.java:48)
Process finished with exit code 0
這時錯誤已經(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)非常清晰明了呢？枚舉式單例也是《Effective Java》書中推薦的一種單例實現(xiàn)寫法。在JDK枚舉的語法特殊性，以及反射也為枚舉保駕護航，讓枚舉式單例成為一種比較優(yōu)雅的實現(xiàn)。
接下來看注冊式單例還有另一種寫法，容器緩存的寫法，創(chuàng)建ContainerSingleton類：
//Spring中的做法，就是用這種注冊式單例
public class ContainerSingleton {
private ContainerSingleton(){}
private static Map<String,Object> ioc = new ConcurrentHashMap<String,Object>();
public static Object getInstance(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);
...
}
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 class ThreadLocalSingletonTest {
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");
}
}
運行結果：
com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@4554617c
com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@4554617c
com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@4554617c
com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@4554617c
com.gupaoedu.vip.pattern.singleton.threadlocal.ThreadLocalSingleton@4554617c
End
Thread-0:com.gupaoedu.vip.pattern.singleton.lazy.LazyDoubleCheckSingleton@51730582
Thread-1:com.gupaoedu.vip.pattern.singleton.lazy.LazyDoubleCheckSingleton@51730582
Process finished with exit code 0
我們發(fā)現(xiàn)，在主線程main中無論調(diào)用多少次，獲取到的實例都是同一個，都在兩個子線程中分別獲取到了不同的實例。那么ThreadLocal是如果實現(xiàn)這樣的效果的呢？我們知
道上面的單例模式為了達到線程安全的目的，給方法上鎖，以時間換空間。ThreadLocal
將所有的對象全部放在ThreadLocalMap中，為每個線程都提供一個對象，實際上是以
空間換時間來實現(xiàn)線程間隔離的。
單例模式小結
單例模式可以保證內(nèi)存里只有一個實例，減少了內(nèi)存開銷；
可以避免對資源的多重占用。
單例模式看起來非常簡單，實現(xiàn)起來其實也非常簡單
項目信息
路漫漫其修遠兮,吾將上下而求索
碼云：https://gitee.com/javacoo
QQ群：164863067
作者/微信：javacoo
郵箱：xihuady@126.com
