Go設計模式--享元模式,節省內存的好幫手
大家好,這里是每周都在陪你一起進步的網管~!今天繼續學習設計模式—享元模式
享元模式是一種結構型設計模式, 它的核心思想是通過共享多個對象所共有的相同狀態,從而有效的支持在有限的內存中載入大量細粒度的對象。
這里著重介紹一下享元這個名詞,享元可以理解為可復用的對象,即可以是對象級別的復用,也可以是對象的字段進行復用(把可復用的字段單獨提煉成一個更精細的對象)。
享元模式的意圖是復用對象,節省內存,前提是享元對象是不可變對象,不可變對象指的是初始化之后,對象的狀態不會改變了,也就是不會存在被修改的情況。
使用場景
當一個系統中有大量的重復對象的時候,如果這些對象是不可變對象,我們就可以使用享元模式,將這些對象設計成享元,在內存只保存一份,供需要的代碼使用,這樣能減少內存中對象的數量,起到節省內存的作用。
實際上,不僅僅相同對象可以設計成享元,對于相似對象,我們也可以將這些對象中相同的部分(字段)提取出來,設計成享元,讓這些大量相似對象引用這些享元。
實現思路
享元模式的實現思路是,在享元對象的工廠類中,通過一個 Map 來緩存已經創建的享元對象,達到復用的目的。接下來我們用一個例子來了解下怎么使用享元模式。
享元模式舉例
假設我們要設計一個多人在線棋牌游戲的平臺。在每個牌局里我們會給用戶發牌然后進行對戰,如果在平臺中每創建一個牌局就需要初始化對應的卡牌,這樣顯然很浪費,因為一套撲克牌里的卡牌是固定的,不管多少個牌局使用的撲克牌都是一樣的,只是牌的玩法不一樣。
撲克牌在這里就相當于不可變對象,創建后即不可改變,而牌局是外在對象,有對應的狀態變化,我們只需要讓每個牌局引用撲克牌這些享元即能達到在有限的內存里多開牌局的目的。
所以我們可以設計一個 pokerCards 存儲多個享元撲克牌對象:
每個牌局創建時程序會設定牌局里的卡牌都引用自pokerCards中的享元
具體牌局的規則是什么該怎么打,這些業務邏輯以及牌局的進行狀態等這些外部狀態都由PokerGame類型來實現,示例代碼這里不再過多著墨說明。這里的重點是享元始終是不可改變的,這樣才能保證享元在系統中只有一份,起到節省內存的作用。
運行程序我們可以驗證,兩個牌局都引用了享元,系統中不存在相同享元對象的多次創建。
本文的完整源碼,已經同步收錄到我整理的電子教程里啦,可向我的公眾號「網管叨bi叨」發送關鍵字【設計模式】領取。
公眾號「網管叨bi叨」發送關鍵字【設計模式】領取。
這里享元模式用代碼實現的比較簡單,主要為了突出享元的不可變,而代表業務當前狀態的外部狀態都是存儲在引用了享元的容器對象中。
下面我們再來用 UML 類圖梳理一下享元模式的結構
享元模式的結構
享元模式的結構中有一下幾個角色:
- Context:上下文或者叫做情景類,包含原始對象中各不相同的外在狀態。 情景與享元對象組合在一起就能表示原始對象的全部狀態。調用享元方法的參數由情景類提供,也可將行為移動到情景類中, 然后將連入的享元作為單純的數據對象。
- Flyweight:享元類,包含原始對象中部分能在多個對象中共享的狀態。 同一享元對象可在許多不同情景中使用。 享元中存儲的狀態被稱為 “內在狀態”。 傳遞給享元方法的狀態被稱為 “外在狀態”。
- FlyweightFactory:享元工廠,會對已有享元的緩存池進行管理。 有了工廠后, 客戶端就無需直接創建享元, 它們只需調用工廠并向其傳遞目標享元的一些內在狀態即可。 工廠會根據參數在之前已創建的享元中進行查找, 如果找到滿足條件的享元就將其返回; 如果沒有找到就根據參數新建享元。
總結
享元模式其實是對象池的一種應用,在應用該模式之前, 我們需要確定程序中確實存在著大量擁有相同狀態(字段)的相似對象同時占用內存的問題。
享元模式的優點是能減少對象的創建,降低內存中對象的數量,降低系統的內存,提高效率。其缺點是 我們在寫程序時需要關注內、外部狀態,關注線程安全問題,使系統、程序的邏輯復雜化。
所以在使用的時候我們需要綜合考慮,確定系統存在大量相似對象占用內村過多的問題,這些對象的一些特征字段也確實能提煉成不可變對象作為享元讓外部對象進行引用,再考慮使用該模式。