一、設計模式
1.1 設計模式是什么?
- 設計模式是解決特定問題的一系列套路,是前輩們的代碼設計經驗的總結,具有一定的普遍性,可以反復使用。其目的是為了提高代碼的可重用性、代碼的可讀性和代碼的可靠性。
- 設計模式的本質是面向對象設計原則的實際運用,是對類的封裝性、繼承性和多態性以及類的關聯關系和組合關系的充分理解。
1.2 為什么要使用設計模式?
項目的需求是永遠在變的,為了應對這種變化,使得我們的代碼能夠輕易的實現解耦和拓展。
1.3 設計模式類型
- 創建型模式
創建型模式的主要關注點是怎樣創建對象,它的主要特點是將對象的創建與使用分離。這樣可以降低系統的耦合度,使用者不需要關注對象的創建細節。
- 結構型模式
結構型模式描述如何將類或對象按某種布局組成更大的結構。它分為類結構型模式和對象結構型模式,前者采用繼承機制來組織接口和類,后者釆用組合或聚合來組合對象。
- 行為型模式
行為型模式用於描述程序在運行時復雜的流程控制,即描述多個類或對象之間怎樣相互協作共同完成單個對象都無法單獨完成的任務,它涉及算法與對象間職責的分配。它分為類行為模式和對象行為模式,前者采用繼承機制來在類間分派行為,后者采用組合或聚合在對象間分配行為。
| 創建型模式 | 結構型模式 | 行為型模式 |
|---|---|---|
| 單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式 | 適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式 | 模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態模式、策略模式、職責鏈模式(責任鏈模式)、訪問者模式 |
二、面向對象設計的六大設計原則
2.1 開閉原則
一個軟件實體如類、模塊和函數應該對擴展開放,對修改關閉
- 解讀
- 用抽象構建框架,用實現擴展細節;
- 不以改動原有類的方式來實現新需求,而是應該以實現事先抽象出來的接口(或具體類繼承抽象類)的方式來實現。
- 優點
- 可以在不改動原有代碼的前提下給程序擴展功能,增加了程序的可擴展性;
- 同時也降低了程序的維護成本。
2.2 單一職責原則
一個類只允許有一個職責,即只有一個導致該類變更的原因。
- 解讀
-
類職責的變化往往就是導致類變化的原因:也就是說如果一個類具有多種職責,就會有多種導致這個類變化的原因,從而導致這個類的維護變得困難;
-
往往在軟件開發中隨着需求的不斷增加,可能會給原來的類添加一些本來不屬於它的一些職責,從而違反了單一職責原則。如果我們發現當前類的職責不僅僅有一個,就應該將本來不屬於該類真正的職責分離出去;
-
不僅僅是類,函數(方法)也要遵循單一職責原則,即:一個函數(方法)只做一件事情。如果發現一個函數(方法)里面有不同的任務,則需要將不同的任務以另一個函數(方法)的形式分離出去。
- 優點
- 提高代碼的可讀性,更實際性地更降低了程序出錯的風險;
- 有利於bug的追蹤,降低了程序的維護成本。
2.3 依賴倒置原則
- 依賴抽象,而不是依賴實現;
- 抽象不應該依賴細節;細節應該依賴抽象;
- 高層模塊不能依賴低層模塊,二者都應該依賴抽象。
- 解讀
- 面向接口編程,而不是面向實現編程;
- 盡量不要從具體的類派生,而是以繼承抽象類或實現接口來實現;
- 關於高層模塊與低層模塊的划分可以按照決策能力的高低進行划分。業務層自然就處於上層模塊,邏輯層和數據層自然就歸類為底層。
- 優點
- 通過抽象來搭建框架,建立類和類的關聯,以減少類間的耦合性;
- 以抽象搭建的系統要比以具體實現搭建的系統更加穩定,擴展性更高,同時也便於維護。
- 里氏替換原則
子類可以擴展父類的功能,但不能改變父類原有的功能。也就是說,子類繼承父類時,除添加新的方法完成新增功能外,盡量不要重寫父類的方法。
2.4 接口隔離原則
多個特定的客戶端接口要好於一個通用性的總接口。
- 解讀
- 客戶端不應該依賴它不需要實現的接口;
- 不建立龐大臃腫的接口,應盡量細化接口,接口中的方法應該盡量少。
注意:接口的粒度也不能太小。如果過小,則會造成接口數量過多,使設計復雜化。
- 優點
避免同一個接口里面包含不同類職責的方法,接口責任划分更加明確,符合高內聚低耦合的思想。
2.5 迪米特法則(最少知道原則)
一個對象應該對盡可能少的對象有接觸,也就是只接觸那些真正需要接觸的對象。
- 解讀
一個類應該只和它的成員變量,方法的輸入,返回參數中的類作交流,而不應該引入其他的類(間接交流)。
- 優點
可以良好地降低類與類之間的耦合,減少類與類之間的關聯程度,讓類與類之間的協作更加直接。
2.6 組合聚合復用原則
所有引用基類的地方必須能透明地使用其子類的對象,也就是說子類對象可以替換其父類對象,而程序執行效果不變。
-解讀
在繼承體系中,子類中可以增加自己特有的方法,也可以實現父類的抽象方法,但是不能重寫父類的非抽象方法,否則該繼承關系就不是一個正確的繼承關系。
- 優點
可以檢驗繼承使用的正確性,約束繼承在使用上的泛濫。
三、 單例模式概念
3.1 單例模式是什么?
單例模式就是在程序運行中只實例化一次,創建一個全局唯一對象。有點像 Java 的靜態變量,但是單例模式要優於靜態變量:
- 靜態變量在程序啟動的時候
JVM就會進行加載,如果不使用,會造成大量的資源浪費; - 單例模式能夠實現懶加載,能夠在使用實例的時候才去創建實例。
開發工具類庫中的很多工具類都應用了單例模式,比例線程池、緩存、日志對象等,它們都只需要創建一個對象,如果創建多份實例,可能會帶來不可預知的問題,比如資源的浪費、結果處理不一致等問題。
3.2 為什么要使用單例模式?
單例模式屬於設計模式三大分類中的第一類——創建型模式,跟對象的創建相關。也就是說,這個模式在創建對象的同時,還致力於控制創建對象的數量,是的,只能創建一個實例,多的不要。
👉那么問題來了,我們為什么要控制對象創建的個數?
- 有些場景下,不使用單例模式,會導致系統同一時刻出現多個狀態缺乏同步,用戶自然無法判斷當前處於什么狀態;
- 通過控制創建對象的數量,可以節約系統資源開銷(像線程、數據庫連接等);
- 全局數據共享。
3.3 單例的實現思路
- 靜態化實例對象;
- 私有化構造方法,禁止通過構造方法創建實例;
- 提供一個公共的靜態方法,用來返回唯一實例。
四、 餓漢模式
在定義靜態屬性時,直接實例化了對象
4.1 示例
public class HungryMode {
/**
* 利用靜態變量來存儲唯一實例
*/
private static final HungryMode instance = new HungryMode();
/**
* 私有化構造函數
*/
private HungryMode(){
// 里面可以有很多操作
}
/**
* 提供公開獲取實例接口
* @return
*/
public static HungryMode getInstance(){
return instance;
}
}
4.2 餓漢模式的優點
由於使用了static關鍵字,保證了在引用這個變量時,關於這個變量的所以寫入操作都完成,所以保證了JVM層面的線程安全。
4.3 餓漢模式的缺點
不能實現懶加載,造成空間浪費:如果一個類比較大,我們在初始化的時就加載了這個類,但是我們長時間沒有使用這個類,這就導致了內存空間的浪費。
所以,能不能只有用到
getInstance()方法,才會去初始化單例類,才會加載單例類中的數據。所以就有了:懶漢式。
五、懶漢模式
懶漢模式是一種偷懶的模式,在程序初始化時不會創建實例,只有在使用實例的時候才會創建實例,所以懶漢模式解決了餓漢模式帶來的空間浪費問題。
5.1 懶漢模式的一般實現
public class LazyMode {
/**
* 定義靜態變量時,未初始化實例
*/
private static LazyMode instance;
/**
* 私有化構造函數
*/
private LazyMode(){
// 里面可以有很多操作
}
/**
* 提供公開獲取實例接口
* @return
*/
public static LazyMode getInstance(){
// 使用時,先判斷實例是否為空,如果實例為空,則實例化對象
if (instance == null) {
instance = new LazyMode();
}
return instance;
}
}
但是這種實現在多線程的情況下是不安全的,有可能會出現多份實例的情況:
if (instance == null) {
instance = new LazyMode();
}
假設有兩個線程同時進入到上面這段代碼,因為沒有任何資源保護措施,所以兩個線程可以同時判斷的 instance 都為空,都將去初始化實例,所以就會出現多份實例的情況。
5.2 懶漢模式的優化
我們給getInstance()方法加上synchronized關鍵字,使得getInstance()方法成為受保護的資源就能夠解決多份實例的問題。
public class LazyModeSynchronized {
/**
* 定義靜態變量時,未初始化實例
*/
private static LazyModeSynchronized instance;
/**
* 私有化構造函數
*/
private LazyModeSynchronized(){
// 里面可以有很多操作
}
/**
* 提供公開獲取實例接口
* @return
*/
public synchronized static LazyModeSynchronized getInstance(){
/**
* 添加class類鎖,影響了性能,加鎖之后將代碼進行了串行化,
* 我們的代碼塊絕大部分是讀操作,在讀操作的情況下,代碼線程是安全的
*
*/
if (instance == null) {
instance = new LazyModeSynchronized();
}
return instance;
}
}
5.3 懶漢模式的優點
實現了懶加載,節約了內存空間。
5.4 懶漢模式的缺點
- 在不加鎖的情況下,線程不安全,可能出現多份實例;
- 在加鎖的情況下,會使程序串行化,使系統有嚴重的性能問題。
懶漢模式中加鎖的問題,對於getInstance()方法來說,絕大部分的操作都是讀操作,讀操作是線程安全的,所以我們沒必讓每個線程必須持有鎖才能調用該方法,我們需要調整加鎖的問題。由此也產生了一種新的實現模式:雙重檢查鎖模式。
六、雙重檢查鎖模式
6.1 雙重檢查鎖模式的一般實現
public class DoubleCheckLockMode {
private static DoubleCheckLockMode instance;
/**
* 私有化構造函數
*/
private DoubleCheckLockMode(){
}
/**
* 提供公開獲取實例接口
* @return
*/
public static DoubleCheckLockMode getInstance(){
// 第一次判斷,如果這里為空,不進入搶鎖階段,直接返回實例
if (instance == null) {
synchronized (DoubleCheckLockMode.class) {
// 搶到鎖之后再次判斷是否為空
if (instance == null) {
instance = new DoubleCheckLockMode();
}
}
}
return instance;
}
}
雙重檢查鎖模式解決了單例、性能、線程安全問題,但是這種寫法同樣存在問題:在多線程的情況下,可能會出現空指針問題,出現問題的原因是JVM在實例化對象的時候會進行優化和指令重排序操作。
6.2 什么是指令重排?
private SingletonObject(){
// 第一步
int x = 10;
// 第二步
int y = 30;
// 第三步
Object o = new Object();
}
上面的構造函數SingletonObject(),JVM 會對它進行指令重排序,所以執行順序可能會亂掉,但是不管是那種執行順序,JVM 最后都會保證所以實例都完成實例化。 如果構造函數中操作比較多時,為了提升效率,JVM 會在構造函數里面的屬性未全部完成實例化時,就返回對象。雙重檢測鎖出現空指針問題的原因就是出現在這里,當某個線程獲取鎖進行實例化時,其他線程就直接獲取實例使用,由於JVM指令重排序的原因,其他線程獲取的對象也許不是一個完整的對象,所以在使用實例的時候就會出現空指針異常問題。
6.3 雙重檢查鎖模式優化
要解決雙重檢查鎖模式帶來空指針異常的問題,只需要使用volatile關鍵字,volatile關鍵字嚴格遵循happens-before原則,即:在讀操作前,寫操作必須全部完成。
public class DoubleCheckLockModelVolatile {
/**
* 添加volatile關鍵字,保證在讀操作前,寫操作必須全部完成
*/
private static volatile DoubleCheckLockModelVolatile instance;
/**
* 私有化構造函數
*/
private DoubleCheckLockModelVolatile(){
}
/**
* 提供公開獲取實例接口
* @return
*/
public static DoubleCheckLockModelVolatile getInstance(){
if (instance == null) {
synchronized (DoubleCheckLockModelVolatile.class) {
if (instance == null) {
instance = new DoubleCheckLockModelVolatile();
}
}
}
return instance;
}
}
七、靜態內部類模式
靜態內部類模式也稱單例持有者模式,實例由內部類創建,由於 JVM 在加載外部類的過程中, 是不會加載靜態內部類的, 只有內部類的屬性/方法被調用時才會被加載, 並初始化其靜態屬性。靜態屬性由static修飾,保證只被實例化一次,並且嚴格保證實例化順序。
public class StaticInnerClassMode {
private StaticInnerClassMode(){
}
/**
* 單例持有者
*/
private static class InstanceHolder{
private final static StaticInnerClassMode instance = new StaticInnerClassMode();
}
/**
* 提供公開獲取實例接口
* @return
*/
public static StaticInnerClassMode getInstance(){
// 調用內部類屬性
return InstanceHolder.instance;
}
}
這種方式跟餓漢式方式采用的機制類似,但又有不同。兩者都是采用了類裝載的機制來保證初始化實例時只有一個線程。不同的地方:
- 餓漢式方式是只要
Singleton類被裝載就會實例化,沒有Lazy-Loading的作用; - 靜態內部類方式在
Singleton類被裝載時並不會立即實例化,而是在需要實例化時,調用getInstance()方法,才會裝載SingletonInstance類,從而完成Singleton的實例化。
類的靜態屬性只會在第一次加載類的時候初始化,所以在這里,JVM幫助我們保證了線程的安全性,在類進行初始化時,別的線程是無法進入的。
所以這種方式在沒有加任何鎖的情況下,保證了多線程下的安全,並且沒有任何性能影響和空間的浪費。
八、枚舉類實現單例模式
因為枚舉類型是線程安全的,並且只會裝載一次,設計者充分的利用了枚舉的這個特性來實現單例模式,枚舉的寫法非常簡單,而且枚舉類型是所用單例實現中唯一一種不會被破壞的單例實現模式。
8.1 示例
public class EnumerationMode {
private EnumerationMode(){
}
/**
* 枚舉類型是線程安全的,並且只會裝載一次
*/
private enum Singleton{
INSTANCE;
private final EnumerationMode instance;
Singleton(){
instance = new EnumerationMode();
}
private EnumerationMode getInstance(){
return instance;
}
}
public static EnumerationMode getInstance(){
return Singleton.INSTANCE.getInstance();
}
}
8.2 適用場合:
- 需要頻繁的進行創建和銷毀的對象;
- 創建對象時耗時過多或耗費資源過多,但又經常用到的對象;
- 工具類對象;
- 頻繁訪問數據庫或文件的對象。
九、單例模式的問題及解決辦法
除枚舉方式外, 其他方法都會通過反射的方式破壞單例
9.1 單例模式的破壞
/**
* 以靜態內部類實現為例
* @throws Exception
*/
@Test
public void singletonTest() throws Exception {
Constructor constructor = StaticInnerClassMode.class.getDeclaredConstructor();
constructor.setAccessible(true);
StaticInnerClassMode obj1 = StaticInnerClassMode.getInstance();
StaticInnerClassMode obj2 = StaticInnerClassMode.getInstance();
StaticInnerClassMode obj3 = (StaticInnerClassMode) constructor.newInstance();
System.out.println("輸出結果為:"+obj1.hashCode()+"," +obj2.hashCode()+","+obj3.hashCode());
}
控制台打印:
輸出結果為:1454171136,1454171136,1195396074
從輸出的結果我們就可以看出obj1和obj2為同一對象,obj3為新對象。obj3是我們通過反射機制,進而調用了私有的構造函數,然后產生了一個新的對象。
9.2 如何阻止單例破壞
可以在構造方法中進行判斷,若已有實例, 則阻止生成新的實例,解決辦法如下:
public class StaticInnerClassModeProtection {
private static boolean flag = false;
private StaticInnerClassModeProtection(){
synchronized(StaticInnerClassModeProtection.class){
if(flag == false){
flag = true;
}else {
throw new RuntimeException("實例已經存在,請通過 getInstance()方法獲取!");
}
}
}
/**
* 單例持有者
*/
private static class InstanceHolder{
private final static StaticInnerClassModeProtection instance = new StaticInnerClassModeProtection();
}
/**
* 提供公開獲取實例接口
* @return
*/
public static StaticInnerClassModeProtection getInstance(){
// 調用內部類屬性
return InstanceHolder.instance;
}
}
測試:
/**
* 在構造方法中進行判斷,若存在則拋出RuntimeException
* @throws Exception
*/
@Test
public void destroyTest() throws Exception {
Constructor constructor = StaticInnerClassModeProtection.class.getDeclaredConstructor();
constructor.setAccessible(true);
StaticInnerClassModeProtection obj1 = StaticInnerClassModeProtection.getInstance();
StaticInnerClassModeProtection obj2 = StaticInnerClassModeProtection.getInstance();
StaticInnerClassModeProtection obj3 = (StaticInnerClassModeProtection) constructor.newInstance();
System.out.println("輸出結果為:"+obj1.hashCode()+"," +obj2.hashCode()+","+obj3.hashCode());
}
控制台打印:
Caused by: java.lang.RuntimeException: 實例已經存在,請通過 getInstance()方法獲取!
at cn.van.singleton.demo.mode.StaticInnerClassModeProtection.<init>(StaticInnerClassModeProtection.java:22)
... 35 more
十、總結
10.1 各種實現的對比
| 名稱 | 餓漢模式 | 懶漢模式 | 雙重檢查鎖模式 | 靜態內部類實現 | 枚舉類實現 |
|---|---|---|---|---|---|
| 可用性 | 可用 | 不推薦使用 | 推薦使用 | 推薦使用 | 推薦使用 |
| 特點 | 不能實現懶加載,可能造成空間浪費 | 不加鎖線程不安全;加鎖性能差 | 線程安全;延遲加載;效率較高 | 避免了線程不安全,延遲加載,效率高。 | 寫法簡單;線程安全;只裝載一次 |

