## 引入
在閻宏博士的《JAVA與模式》一書中開頭是這樣描述享元(Flyweight)模式的:
> Flyweight在拳擊比賽中指最輕量級,即“蠅量級”或“雨量級”,這里選擇使用“享元模式”的意譯,是因為這樣更能反映模式的用意。享元模式是對象的結構模式。享元模式以共享的方式高效地支持大量的細粒度對象。
面向對象可以非常方便的解決一些擴展性的問題,但是在這個過程中系統務必會產生一些類或者對象,如果系統中存在對象的個數過多時,將會導致系統的性能下降。對于這樣的問題解決最簡單直接的辦法就是減少系統中對象的個數。
享元模式提供了一種解決方案,使用共享技術實現相同或者相似對象的重用。也就是說實現相同或者相似對象的代碼共享。
在JAVA語言中,String類型就是使用了享元模式。String對象是final類型,對象一旦創建就不可改變。在JAVA中字符串常量都是存在常量池中的,JAVA會確保一個字符串常量在常量池中只有一個拷貝。String a="abc",其中"abc"就是一個字符串常量。
~~~
public class Test {
public static void main(String[] args) {
String a = "abc";
String b = "abc";
System.out.println(a==b);
}
}
~~~
上面的例子中結果為:true ,這就說明a和b兩個引用都指向了常量池中的同一個字符串常量"abc"。這樣的設計避免了在創建N多相同對象時所產生的不必要的大量的資源消耗。
## 定義
所謂享元模式就是運用共享技術有效地支持大量細粒度對象的復用。享元模式采用一個共享來避免大量擁有相同內容對象的開銷。這種開銷最常見、最直觀的就是內存的損耗。享元對象能做到共享的關鍵是區分內蘊狀態(Internal State)和外蘊狀態(External State)。
共享模式是支持大量細粒度對象的復用,所以享元模式要求能夠共享的對象必須是細粒度對象。
**內蘊狀態**是存儲在享元對象內部的,并且是不會隨環境的改變而有所不同。因此,一個享元可以具有內蘊狀態并可以共享。
**外蘊狀態**是隨環境的改變而改變的、不可以共享的。享元對象的外蘊狀態必須由客戶端保存,并在享元對象被創建之后,在需要使用的時候再傳入到享元對象內部。外蘊狀態不可以影響享元對象的內蘊狀態,它們是相互獨立的。
由于享元模式區分了內部狀態和外部狀態,所以我們可以通過設置不同的外部狀態使得相同的對象可以具備一些不同的特性,而內部狀態設置為相同部分。在我們的程序設計過程中,我們可能會需要大量的細粒度對象來表示對象,如果這些對象除了幾個參數不同外其他部分都相同,這個時候我們就可以利用享元模式來大大減少應用程序當中的對象。如何利用享元模式呢?這里我們只需要將他們少部分的不同的部分當做參數移動到類實例的外部去,然后再方法調用的時候將他們傳遞過來就可以了。這里也就說明了一點:內部狀態存儲于享元對象內部,而外部狀態則應該由客戶端來考慮。
## 結構和代碼實現
享元模式可以分成單純享元模式和復合享元模式兩種形式。
### 單純享元模式
**結構**
在單純的享元模式中,所有的享元對象都是可以共享的。

單純享元模式所涉及到的角色如下:
* 抽象享元(Flyweight)角色 :給出一個抽象接口,以規定出所有具體享元角色需要實現的方法。
* 具體享元(ConcreteFlyweight)角色:實現抽象享元角色所規定出的接口。如果有內蘊狀態的話,必須負責為內蘊狀態提供存儲空間。
* 享元工廠(FlyweightFactory)角色 :本角色負責創建和管理享元角色。本角色必須保證享元對象可以被系統適當地共享。當一個客戶端對象調用一個享元對象的時候,享元工廠角色會檢查系統中是否已經有一個符合要求的享元對象。如果已經有了,享元工廠角色就應當提供這個已有的享元對象;如果系統中沒有一個適當的享元對象的話,享元工廠角色就應當創建一個合適的享元對象。
**代碼實現**
抽象享元角色類
~~~
public interface Flyweight {
//一個示意性方法,參數state是外蘊狀態
public void operation(String state);
}
~~~
具體享元角色類ConcreteFlyweight有一個內蘊狀態,在本例中一個Character類型的intrinsicState屬性代表,它的值應當在享元對象被創建時賦予。所有的內蘊狀態在對象創建之后,就不會再改變了。
如果一個享元對象有外蘊狀態的話,所有的外部狀態都必須存儲在客戶端,在使用享元對象時,再由客戶端傳入享元對象。這里只有一個外蘊狀態,operation()方法的參數state就是由外部傳入的外蘊狀態。
~~~
public class ConcreteFlyweight implements Flyweight {
private Character intrinsicState = null;
/**
* 構造函數,內蘊狀態作為參數傳入
* @param state
*/
public ConcreteFlyweight(Character state){
this.intrinsicState = state;
}
/**
* 外蘊狀態作為參數傳入方法中,改變方法的行為,
* 但是并不改變對象的內蘊狀態。
*/
@Override
public void operation(String state) {
// TODO Auto-generated method stub
System.out.println("Intrinsic State = " + this.intrinsicState);
System.out.println("Extrinsic State = " + state);
}
}
~~~
享元工廠角色類,必須指出的是,客戶端不可以直接將具體享元類實例化,而必須通過一個工廠對象,利用一個factory()方法得到享元對象。一般而言,享元工廠對象在整個系統中只有一個,因此也可以使用單例模式。
當客戶端需要單純享元對象的時候,需要調用享元工廠的factory()方法,并傳入所需的單純享元對象的內蘊狀態,由工廠方法產生所需要的享元對象。
~~~
public class FlyweightFactory {
private Map<Character,Flyweight> files = new HashMap<Character,Flyweight>();
public Flyweight factory(Character state){
//先從緩存中查找對象
Flyweight fly = files.get(state);
if(fly == null){
//如果對象不存在則創建一個新的Flyweight對象
fly = new ConcreteFlyweight(state);
//把這個新的Flyweight對象添加到緩存中
files.put(state, fly);
}
return fly;
}
}
~~~
客戶端類
~~~
public class Client {
public static void main(String[] args) {
// TODO Auto-generated method stub
FlyweightFactory factory = new FlyweightFactory();
Flyweight fly = factory.factory(new Character('a'));
fly.operation("First Call");
fly = factory.factory(new Character('b'));
fly.operation("Second Call");
fly = factory.factory(new Character('a'));
fly.operation("Third Call");
}
}
~~~
雖然客戶端申請了三個享元對象,但是實際創建的享元對象只有兩個,這就是共享的含義。運行結果如下:

### 復合享元模式
**結構**
在單純享元模式中,所有的享元對象都是單純享元對象,也就是說都是可以直接共享的。還有一種較為復雜的情況,將一些單純享元使用合成模式加以復合,形成復合享元對象。這樣的復合享元對象本身不能共享,但是它們可以分解成單純享元對象,而后者則可以共享。

復合享元角色所涉及到的角色如下:
* 抽象享元(Flyweight)角色 :給出一個抽象接口,以規定出所有具體享元角色需要實現的方法。
* 具體享元(ConcreteFlyweight)角色:實現抽象享元角色所規定出的接口。如果有內蘊狀態的話,必須負責為內蘊狀態提供存儲空間。
* 復合享元(ConcreteCompositeFlyweight)角色 :復合享元角色所代表的對象是不可以共享的,但是一個復合享元對象可以分解成為多個本身是單純享元對象的組合。復合享元角色又稱作不可共享的享元對象。
* 享元工廠(FlyweightFactory)角色 :本角 色負責創建和管理享元角色。本角色必須保證享元對象可以被系統適當地共享。當一個客戶端對象調用一個享元對象的時候,享元工廠角色會檢查系統中是否已經有 一個符合要求的享元對象。如果已經有了,享元工廠角色就應當提供這個已有的享元對象;如果系統中沒有一個適當的享元對象的話,享元工廠角色就應當創建一個 合適的享元對象。
**代碼實現**
抽象享元角色類
~~~
public interface Flyweight {
//一個示意性方法,參數state是外蘊狀態
public void operation(String state);
}
~~~
具體享元角色類
~~~
public class ConcreteFlyweight implements Flyweight {
private Character intrinsicState = null;
/**
* 構造函數,內蘊狀態作為參數傳入
* @param state
*/
public ConcreteFlyweight(Character state){
this.intrinsicState = state;
}
/**
* 外蘊狀態作為參數傳入方法中,改變方法的行為,
* 但是并不改變對象的內蘊狀態。
*/
@Override
public void operation(String state) {
// TODO Auto-generated method stub
System.out.println("Intrinsic State = " + this.intrinsicState);
System.out.println("Extrinsic State = " + state);
}
}
~~~
復合享元對象是由單純享元對象通過復合而成的,因此它提供了add()這樣的聚集管理方法。由于一個復合享元對象具有不同的聚集元素,這些聚集元素在復合享元對象被創建之后加入,這本身就意味著復合享元對象的狀態是會改變的,因此復合享元對象是不能共享的。
復合享元角色實現了抽象享元角色所規定的接口,也就是operation()方法,這個方法有一個參數,代表復合享元對象的外蘊狀態。一個復合享元對象的所有單純享元對象元素的外蘊狀態都是與復合享元對象的外蘊狀態相等的;而一個復合享元對象所含有的單純享元對象的內蘊狀態一般是不相等的,不然就沒有使用價值了。
~~~
public class ConcreteCompositeFlyweight implements Flyweight {
private Map<Character,Flyweight> files = new HashMap<Character,Flyweight>();
/**
* 增加一個新的單純享元對象到聚集中
*/
public void add(Character key , Flyweight fly){
files.put(key,fly);
}
/**
* 外蘊狀態作為參數傳入到方法中
*/
@Override
public void operation(String state) {
Flyweight fly = null;
for(Object o : files.keySet()){
fly = files.get(o);
fly.operation(state);
}
}
}
~~~
享元工廠角色提供兩種不同的方法,一種用于提供單純享元對象,另一種用于提供復合享元對象。
~~~
public class FlyweightFactory {
private Map<Character,Flyweight> files = new HashMap<Character,Flyweight>();
/**
* 復合享元工廠方法
*/
public Flyweight factory(List<Character> compositeState){
ConcreteCompositeFlyweight compositeFly = new ConcreteCompositeFlyweight();
for(Character state : compositeState){
compositeFly.add(state,this.factory(state));
}
return compositeFly;
}
/**
* 單純享元工廠方法
*/
public Flyweight factory(Character state){
//先從緩存中查找對象
Flyweight fly = files.get(state);
if(fly == null){
//如果對象不存在則創建一個新的Flyweight對象
fly = new ConcreteFlyweight(state);
//把這個新的Flyweight對象添加到緩存中
files.put(state, fly);
}
return fly;
}
}
~~~
客戶端角色
~~~
public class Client {
public static void main(String[] args) {
List<Character> compositeState = new ArrayList<Character>();
compositeState.add('a');
compositeState.add('b');
compositeState.add('c');
compositeState.add('a');
compositeState.add('b');
FlyweightFactory flyFactory = new FlyweightFactory();
Flyweight compositeFly1 = flyFactory.factory(compositeState);
Flyweight compositeFly2 = flyFactory.factory(compositeState);
compositeFly1.operation("Composite Call");
System.out.println("---------------------------------");
System.out.println("復合享元模式是否可以共享對象:" + (compositeFly1 == compositeFly2));
Character state = 'a';
Flyweight fly1 = flyFactory.factory(state);
Flyweight fly2 = flyFactory.factory(state);
System.out.println("單純享元模式是否可以共享對象:" + (fly1 == fly2));
}
}
~~~
運行結果如下:

從運行結果可以看出,一個復合享元對象的所有單純享元對象元素的外蘊狀態都是與復合享元對象的外蘊狀態相等的。即外運狀態都等于Composite Call。
從運行結果可以看出,一個復合享元對象所含有的單純享元對象的內蘊狀態一般是不相等的。即內蘊狀態分別為b、c、a。
從運行結果可以看出,復合享元對象是不能共享的。即使用相同的對象compositeState通過工廠分別兩次創建出的對象不是同一個對象。
從運行結果可以看出,單純享元對象是可以共享的。即使用相同的對象state通過工廠分別兩次創建出的對象是同一個對象。
## 優點
* 1、享元模式的優點在于它能夠極大的減少系統中對象的個數。
* 2、享元模式由于使用了外部狀態,外部狀態相對獨立,不會影響到內部狀態,所以享元模式使得享元對象能夠在不同的環境被共享。
## 缺點
* 1、由于享元模式需要區分外部狀態和內部狀態,使得應用程序在某種程度上來說更加復雜化了。
* 2、為了使對象可以共享,享元模式需要將享元對象的狀態外部化,而讀取外部狀態使得運行時間變長。
## 適用場景
* 1、如果一個系統中存在大量的相同或者相似的對象,由于這類對象的大量使用,會造成系統內存的耗費,可以使用享元模式來減少系統中對象的數量。
* 2、對象的大部分狀態都可以外部化,可以將這些外部狀態傳入對象中。
## 總結
* 1、享元模式可以極大地減少系統中對象的數量。但是它可能會引起系統的邏輯更加復雜化。
* 2、享元模式的核心在于享元工廠,它主要用來確保合理地共享享元對象。
* 3、內部狀態為不變共享部分,存儲于享元享元對象內部,而外部狀態是可變部分,它應當油客戶端來負責。
- java
- 設計模式
- 設計模式總覽
- 設計原則
- 工廠方法模式
- 抽象工廠模式
- 單例模式
- 建造者模式
- 原型模式
- 適配器模式
- 裝飾者模式
- 代理模式
- 外觀模式
- 橋接模式
- 組合模式
- 享元模式
- 策略模式
- 模板方法模式
- 觀察者模式
- 迭代子模式
- 責任鏈模式
- 命令模式
- 備忘錄模式
- 狀態模式
- 訪問者模式
- 中介者模式
- 解釋器模式
- 附錄
- JVM相關
- JVM內存結構
- Java虛擬機的內存組成以及堆內存介紹
- Java堆和棧
- 附錄-數據結構的堆棧和內存分配的堆區棧區的區別
- Java內存之Java 堆
- Java內存之虛擬機和內存區域概述
- Java 內存之方法區和運行時常量池
- Java 內存之直接內存(堆外內存)
- JAVA內存模型
- Java內存模型介紹
- 內存模型如何解決緩存一致性問題
- 深入理解Java內存模型——基礎
- 深入理解Java內存模型——重排序
- 深入理解Java內存模型——順序一致性
- 深入理解Java內存模型——volatile
- 深入理解Java內存模型——鎖
- 深入理解Java內存模型——final
- 深入理解Java內存模型——總結
- 內存可見性
- JAVA對象模型
- JVM內存結構 VS Java內存模型 VS Java對象模型
- Java的對象模型
- Java的對象頭
- HotSpot虛擬機
- HotSpot虛擬機對象探秘
- 深入分析Java的編譯原理
- Java虛擬機的鎖優化技術
- 對象和數組并不是都在堆上分配內存的
- 垃圾回收
- JVM內存管理及垃圾回收
- JVM 垃圾回收器工作原理及使用實例介紹
- JVM內存回收理論與實現(對象存活的判定)
- JVM參數及調優
- CMS GC日志分析
- JVM實用參數(一)JVM類型以及編譯器模式
- JVM實用參數(二)參數分類和即時(JIT)編譯器診斷
- JVM實用參數(三)打印所有XX參數及值
- JVM實用參數(四)內存調優
- JVM實用參數(五)新生代垃圾回收
- JVM實用參數(六) 吞吐量收集器
- JVM實用參數(七)CMS收集器
- JVM實用參數(八)GC日志
- Java性能調優原則
- JVM 優化經驗總結
- 面試題整理
- 面試題1
- java日志規約
- Spring安全
- OAtuth2.0簡介
- Spring Session 簡介(一)
- Spring Session 簡介(二)
- Spring Session 簡介(三)
- Spring Security 簡介(一)
- Spring Security 簡介(二)
- Spring Security 簡介(三)
- Spring Security 簡介(四)
- Spring Security 簡介(五)
- Spring Security Oauth2 (一)
- Spring Security Oauth2 (二)
- Spring Security Oauth2 (三)
- SpringBoot
- Shiro
- Shiro和Spring Security對比
- Shiro簡介
- Session、Cookie和Cache
- Web Socket
- Spring WebFlux