單例模式的應(yīng)用場(chǎng)景
單例模式（Singleton Pattern）是指確保一個(gè)類在任何情況下都絕對(duì)只有一個(gè)實(shí)例，并提供一個(gè)全局訪問(wèn)點(diǎn)。單例模式是創(chuàng)建型模式。單例模式在現(xiàn)實(shí)生活中應(yīng)用也非常廣泛。 例如，國(guó)家主席、公司 CEO、部門經(jīng)理等。在 J2EE 標(biāo)準(zhǔn)中，ServletContext、 ServletContextConfig 等；在 Spring 框架應(yīng)用中 ApplicationContext；數(shù)據(jù)庫(kù)的連接池也都是單例形式。
餓漢式單例
餓漢式單例是在類加載的時(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)看一段代碼：
//餓漢式單例
// 它是在類加載的時(shí)候就立即初始化，并且創(chuàng)建單例對(duì)象
//優(yōu)點(diǎn)：沒(méi)有加任何的鎖、執(zhí)行效率比較高，
//在用戶體驗(yàn)上來(lái)說(shuō)，比懶漢式更好
//缺點(diǎn)：類加載的時(shí)候就初始化，不管你用還是不用，我都占著空間
//浪費(fèi)了內(nèi)存，有可能占著茅坑不拉屎
//絕對(duì)線程安全，在線程還沒(méi)出現(xiàn)以前就是實(shí)例化了，不可能存在訪問(wèn)安全問(wèn)題
public class HungrySingleton {
//先靜態(tài)、后動(dòng)態(tài)
//先屬性、后方法
//先上后下
private static final HungrySingleton hungrySingleton = new HungrySingleton();
private HungrySingleton(){}
public static HungrySingleton getInstance(){
return hungrySingleton;
}
}
還有另外一種寫(xiě)法，利用靜態(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;
}
}
這兩種寫(xiě)法都非常的簡(jiǎn)單，也非常好理解，餓漢式適用在單例對(duì)象較少的情況。下面我 們來(lái)看性能更優(yōu)的寫(xiě)法。
懶漢式單例
懶漢式單例的特點(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 synchronized static LazySimpleSingleton getInstance(){
if(lazy == null){
lazy = new LazySimpleSingleton();
}
return lazy;
}
}
然后寫(xiě)一個(gè)線程類 ExectorThread 類：
public class ExectorThread implements Runnable{
public void run() {
LazySimpleSingleton singleton = LazySimpleSingleton.getInstance();
// ThreadLocalSingleton singleton = ThreadLocalSingleton.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é)果的情況，意味著上面的單例存在線程安全隱患存在線程不安全的情況。那么，我們?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;
}
}
線程安全的問(wèn)題便解決了。但是，用 synchronized 加鎖，在線程數(shù)量比較多情況下，如果 CPU 分配壓力上升，會(huì)導(dǎo)致大批 量線程出現(xiàn)阻塞，從而導(dǎo)致程序運(yùn)行性能大幅下降。那么，有沒(méi)有一種更好的方式，既 兼顧線程安全又提升程序性能呢？答案是肯定的。我們來(lái)看雙重檢查鎖的單例模式：
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)存地址
//4.初次訪問(wèn)對(duì)象
}
}
}
return lazy;
}
}
當(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)
//史上最牛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ì)被重寫(xiě)，重載
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)單。
序列化破壞單例
當(dāng)我們將一個(gè)單例對(duì)象創(chuàng)建好，有時(shí)候需要將對(duì)象序列化然后寫(xiě)入到磁盤，下次使用時(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流，寫(xiě)入到其他地方(可以是磁盤、網(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;
}
}
編寫(xiě)測(cè)試代碼：
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();
}
}
}
運(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)化代碼：
//反序列化時(shí)導(dǎo)致單例破壞
public class SeriableSingleton implements Serializable {
//序列化就是說(shuō)把內(nèi)存中的狀態(tài)通過(guò)轉(zhuǎn)換成字節(jié)碼的形式
//從而轉(zhuǎn)換一個(gè)IO流，寫(xiě)入到其他地方(可以是磁盤、網(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;
}
}
注冊(cè)式單例
注冊(cè)式單例又稱為登記式單例，就是將每一個(gè)實(shí)例都登記到某一個(gè)地方，使用唯一的標(biāo) 識(shí)獲取實(shí)例。注冊(cè)式單例有兩種寫(xiě)法：一種為容器緩存，一種為枚舉登記。先來(lái)看枚舉 式單例的寫(xiě)法，來(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();
}
}
}
沒(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)行報(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)非常清晰明了呢？枚舉式單例也是《Effective Java》書(shū)中推薦的一種單例實(shí)現(xiàn)寫(xiě)法。在 JDK 枚舉的語(yǔ)法特殊性，以及反射也為枚舉保 駕護(hù)航，讓枚舉式單例成為一種比較優(yōu)雅的實(shí)現(xiàn)。 接下來(lái)看注冊(cè)式單例還有另一種寫(xiě)法，容器緩存的寫(xiě)法，創(chuàng)建 ContainerSingleton 類：
//Spring中的做法，就是用這種注冊(cè)式單例
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);
}
}
}
}
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();
}
}
寫(xiě)一下測(cè)試代碼：
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");
}
}
我們發(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ì)單例模式有非常深刻的掌握，在面試中彰顯技術(shù) 深度，提升核心競(jìng)爭(zhēng)力
