享元模式

深入理解享元模式：优化对象创建的高效设计模式

在软件开发中，对象的创建和管理往往是影响系统性能的关键因素之一。当系统需要频繁创建大量相似对象，且这些对象中存在大量重复数据时，会造成内存资源的严重浪费，同时也会增加系统的负载。为解决这一问题，享元模式（Flyweight Pattern） 应运而生。它通过共享技术来高效地支持大量细粒度对象的复用，是一种常用的结构型设计模式。

一、享元模式的定义与核心思想

享元模式的官方定义为：运用共享技术有效地支持大量细粒度的对象。其核心思想在于将对象的属性划分为 “内部状态（Intrinsic State）” 和 “外部状态（Extrinsic State）”，从而实现对象的复用。

• 内部状态：指对象中不随环境变化而改变的属性，这些属性是可以被多个对象共享的。例如，在一个文档编辑系统中，字符的字体、字号、颜色等属性，对于同一类字符（如所有的 “a” 字符）来说是固定的，属于内部状态。

• 外部状态：指对象中随环境变化而改变的属性，这些属性不能被共享，需要由客户端在使用时自行传入。例如，字符在文档中的位置（行号、列号），不同的 “a” 字符在文档中位置不同，属于外部状态。

享元模式的本质就是提取对象的内部状态，将其封装在享元对象中并进行共享，而外部状态则由客户端根据实际场景动态设置，这样就可以极大地减少系统中对象的数量，节省内存空间，提高系统性能。

二、享元模式的组成角色

为了实现共享对象的创建、管理和使用，享元模式通常包含以下四个核心角色，各角色之间相互配合，共同完成享元对象的复用流程。

1. 抽象享元角色（Flyweight）

抽象享元角色是一个抽象类或接口，它定义了享元对象的公共方法，这些方法可以接收并作用于外部状态。同时，它也声明了获取内部状态的方法，为具体享元角色提供了统一的接口规范。

例如，在一个图形系统中，抽象享元角色可以定义为 “Shape” 接口，其中包含 “draw (int x, int y)” 方法（用于接收外部状态 “位置坐标” 并绘制图形）和 “getColor ()” 方法（用于获取内部状态 “颜色”）。

2. 具体享元角色（Concrete Flyweight）

具体享元角色实现了抽象享元角色所定义的接口，它负责存储内部状态。在具体享元角色中，内部状态是固定不变的，并且可以被多个客户端共享。当客户端调用具体享元角色的方法时，会将外部状态作为参数传入，方法会根据内部状态和外部状态的组合来执行相应的操作。

以图形系统为例，具体享元角色可以是 “Circle” 类（圆形）和 “Rectangle” 类（矩形）。在 “Circle” 类中，内部状态 “颜色（color）” 被定义为成员变量并在构造函数中初始化，而 “draw (int x, int y)” 方法则会根据传入的外部状态 “位置（x,y）” 和内部状态 “颜色” 来绘制圆形。

3. 享元工厂角色（Flyweight Factory）

享元工厂角色是享元模式的核心，它负责创建和管理享元对象。享元工厂维护了一个 “享元池（Flyweight Pool）”，该池用于存储已经创建的具体享元对象，并且会根据客户端的请求来判断是否需要创建新的享元对象。

当客户端向享元工厂请求一个享元对象时，享元工厂会先检查享元池中是否已经存在具有相同内部状态的享元对象：

• 如果存在，则直接将该享元对象返回给客户端；

• 如果不存在，则创建一个新的具体享元对象，将其存入享元池中，然后再返回给客户端。

通过这种方式，享元工厂确保了具有相同内部状态的享元对象只被创建一次，实现了对象的复用。例如，在图形系统的享元工厂中，如果客户端请求一个 “红色” 的圆形，工厂会先检查池中是否有 “红色” 圆形，若有则直接返回，若无则创建新的 “红色” 圆形并加入池中。

4. 客户端角色（Client）

客户端角色负责创建外部状态，并向享元工厂请求享元对象。客户端需要知道抽象享元角色和享元工厂角色，但不需要直接创建具体享元角色。在使用享元对象时，客户端会将外部状态传入享元对象的方法中，以完成相应的业务逻辑。

例如，在文档编辑系统中，客户端（如文档编辑器）在用户输入字符时，会确定字符的位置（外部状态），然后向享元工厂请求对应的字符享元对象（如 “a” 字符，内部状态为 “宋体、12 号、黑色”），最后调用享元对象的方法将字符绘制在指定位置。

三、享元模式的实现案例：文档字符处理系统

为了更直观地理解享元模式的应用，我们以一个简单的文档字符处理系统为例，详细讲解享元模式的实现过程。

1. 需求分析

在文档编辑过程中，用户会输入大量的字符，这些字符具有相同的字体、字号和颜色（内部状态），但位置不同（外部状态）。如果为每个字符都创建一个独立的对象，会导致系统中对象数量激增，浪费内存资源。因此，我们可以使用享元模式来复用具有相同内部状态的字符对象，只存储不同的外部状态（位置）。

2. 代码实现

（1）抽象享元角色：Character（字符接口）

// 抽象享元角色：字符接口

public interface Character {

   // 绘制字符（接收外部状态：位置坐标x、y）

   void display(int x, int y);

   // 获取字符的内部状态：字体

   String getFont();

   // 获取字符的内部状态：字号

   int getFontSize();

   // 获取字符的内部状态：颜色

   String getColor();

}

（2）具体享元角色：ConcreteCharacter（具体字符类）

// 具体享元角色：具体字符类

public class ConcreteCharacter implements Character {

   // 内部状态：字体（固定不变，可共享）

   private String font;

   // 内部状态：字号（固定不变，可共享）

   private int fontSize;

   // 内部状态：颜色（固定不变，可共享）

   private String color;

   // 字符内容（如'a'、'b'，属于内部状态，不同字符内容对应不同享元对象）

   private char content;

   // 构造函数：初始化内部状态

   public ConcreteCharacter(char content, String font, int fontSize, String color) {

       this.content = content;

       this.font = font;

       this.fontSize = fontSize;

       this.color = color;

   }

   @Override

   public void display(int x, int y) {

       // 根据内部状态（字体、字号、颜色、字符内容）和外部状态（位置x、y）绘制字符

       System.out.printf("在位置(%d, %d)绘制字符：'%c'，字体：%s，字号：%d，颜色：%s%n",

               x, y, content, font, fontSize, color);

   }

   @Override

   public String getFont() {

       return font;

   }

   @Override

   public int getFontSize() {

       return fontSize;

   }

   @Override

   public String getColor() {

       return color;

   }

   // 获取字符内容（用于享元工厂判断是否存在相同内部状态的享元对象）

   public char getContent() {

       return content;

   }

}

（3）享元工厂角色：CharacterFactory（字符工厂类）

import java.util.HashMap;

import java.util.Map;

// 享元工厂角色：字符工厂类

public class CharacterFactory {

   // 享元池：存储具体享元对象，key为字符内容（content）+字体（font）+字号（fontSize）+颜色（color）的组合

   private Map<String, Character> characterPool = new HashMap<>();

   // 获取享元对象的方法

   public Character getCharacter(char content, String font, int fontSize, String color) {

       // 生成享元对象的key（根据内部状态组合）

       String key = content + "_" + font + "_" + fontSize + "_" + color;

       // 检查享元池中是否存在该享元对象

       if (!characterPool.containsKey(key)) {

           // 若不存在，则创建新的具体享元对象并加入享元池

           Character character = new ConcreteCharacter(content, font, fontSize, color);

           characterPool.put(key, character);

           System.out.printf("创建新的字符享元对象，key：%s%n", key);

       } else {

           // 若存在，则直接从享元池获取

           System.out.printf("从享元池获取字符享元对象，key：%s%n", key);

       }

       return characterPool.get(key);

   }

   // 获取享元池中享元对象的数量（用于测试，查看复用效果）

   public int getPoolSize() {

       return characterPool.size();

   }

}

（4）客户端角色：DocumentEditor（文档编辑器类）

// 客户端角色：文档编辑器类

public class DocumentEditor {

   public static void main(String[] args) {

       // 创建享元工厂

       CharacterFactory characterFactory = new CharacterFactory();

       // 模拟用户输入文档内容："Hello World!"，每个字符的位置不同（外部状态），但字体、字号、颜色相同（内部状态）

       String documentContent = "Hello World!";

       String font = "宋体";

       int fontSize = 12;

       String color = "黑色";

       // 遍历文档内容，获取每个字符的享元对象并绘制

       for (int i = 0; i < documentContent.length(); i++) {

           char content = documentContent.charAt(i);

           // 从享元工厂获取享元对象（内部状态：content、font、fontSize、color）

           Character character = characterFactory.getCharacter(content, font, fontSize, color);

           // 绘制字符（传入外部状态：位置x=i*20，y=50，x坐标随字符索引递增，模拟横向排列）

           character.display(i * 20, 50);

       }

       // 输出享元池中享元对象的数量（文档内容有12个字符，但不同字符内容只有8个：H,e,l,o, ,W,r,d,!）

       System.out.printf("享元池中享元对象的数量：%d%n", characterFactory.getPoolSize());

   }

}

3. 运行结果与分析

运行客户端代码后，输出结果如下：

创建新的字符享元对象，key：H_宋体_12_黑色

在位置(0, 50)绘制字符：'H'，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key：e_宋体_12_黑色

在位置(20, 50)绘制字符：'e'，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key：l_宋体_12_黑色

在位置(40, 50)绘制字符：'l'，字体：宋体，字号：12，颜色：黑色

在位置(60, 50)绘制字符：'l'，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key：o_宋体_12_黑色

在位置(80, 50)绘制字符：'o'，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key： _宋体_12_黑色

在位置(100, 50)绘制字符：' '，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key：W_宋体_12_黑色

在位置(120, 50)绘制字符：'W'，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key：r_宋体_12_黑色

在位置(140, 50)绘制字符：'r'，字体：宋体，字号：12，颜色：黑色

在位置(160, 50)绘制字符：'l'，字体：宋体，字号：12，颜色：黑色

在位置(180, 50)绘制字符：'d'，字体：宋体，字号：12，颜色：黑色

创建新的字符享元对象，key：!_宋体_12_黑色

在位置(200, 50)绘制字符：'!'，字体：宋体，字号：12，颜色：黑色

享元池中享元对象的数量：8

从运行结果可以看出：

• 文档内容 “Hello World!” 共有 12 个字符，但由于 “l” 字符出现了 3 次、“d” 字符出现了 2 次，其他字符各出现 1 次，因此享元池中只创建了 8 个享元对象，实现了对象的复用；

• 当客户端再次请求相同内部状态的字符对象时（如第二次和第三次请求 “l” 字符），享元工厂直接从享元池中获取，而不是创建新对象，极大地减少了对象的创建数量，节省了内存资源。

四、享元模式的优缺点

1. 优点

• 节省内存资源：享元模式通过共享具有相同内部状态的对象，避免了大量相似对象的重复创建，显著减少了系统中对象的数量，从而节省了内存空间，降低了内存溢出的风险。

• 提高系统性能：减少对象的创建和销毁次数，可以降低系统的开销，提高系统的运行效率。同时，由于对象数量减少，系统的垃圾回收压力也会相应减轻。

• 灵活性高：外部状态由客户端动态设置，使得享元对象可以在不同的环境中被复用，增强了系统的灵活性和可扩展性。

2. 缺点

• 增加系统复杂度：享元模式需要将对象的属性划分为内部状态和外部状态，并且需要创建享元工厂来管理享元对象，这会增加系统的类结构和代码复杂度，不利于后期的维护和理解。

• 外部状态管理成本高：外部状态需要由客户端进行管理和传递，如果外部状态较为复杂，会增加客户端的代码复杂度，同时也可能因为外部状态的错误传递导致系统出现问题。

• 线程安全问题：如果多个线程同时操作享元对象的外部状态，可能会出现线程安全问题。因此，在多线程环境下，需要对享元对象的外部状态进行同步处理，这会增加系统的开销。

五、享元模式的适用场景

享元模式并非在所有场景下都适用，它主要适用于以下几种情况：

1. 系统中存在大量相似对象

当系统需要创建大量具有相同或相似属性（内部状态）的对象时，使用享元模式可以显著减少对象的数量，节省内存资源。例如，文档中的字符、游戏中的粒子效果、网站中的图标等。

2. 对象的大部分属性可以作为内部状态

如果对象的大部分属性是固定不变的（可以作为内部状态），只有少数属性是随环境变化的（可以作为外部状态），那么使用享元模式可以充分发挥共享的优势。反之，如果对象的大部分属性是外部状态，那么共享的意义不大，反而会增加系统的复杂度。

3. 客户端不依赖于对象的标识

享元模式中的享元对象是被多个客户端共享的，因此客户端不能依赖于对象的唯一标识（如对象的引用地址）来区分不同的对象。如果客户端需要通过对象标识来进行操作（如修改对象的内部状态），则不适合使用享元模式。

4. 系统需要追求内存优化

在内存资源有限的场景下（如移动设备应用、嵌入式系统等），使用享元模式可以有效减少内存的占用，提高系统的运行效率。

六、享元模式与其他设计模式的对比

1. 享元模式 vs 单例模式

• 单例模式：确保一个类只有一个实例，并且提供一个全局访问点。单例模式的核心是 “唯一实例”，适用于整个系统中只需要一个对象的场景（如配置管理器、日志管理器等）。

• 享元模式：确保具有相同内部状态的对象只有一个实例，通过享元池来管理多个共享实例。享元模式的核心是 “对象复用”，适用于需要大量相似对象的场景。

• 区别：单例模式是 “一个类一个实例”，而享元模式是 “一类内部状态一个实例”；单例模式的实例是全局唯一的，而享元模式的实例是在享元池中共享的。

2. 享元模式 vs 原型模式

• 原型模式：通过复制现有对象（原型）来创建新对象，适用于对象创建成本较高（如初始化过程复杂、耗时）的场景。原型模式的核心是 “对象复制”，新对象与原型对象是独立的，修改新对象的属性不会影响原型对象。

• 享元模式：通过共享现有对象来避免创建新对象，适用于对象数量庞大且相似的场景。享元模式的核心是 “对象共享”，多个客户端共享同一个享元对象，修改享元对象的外部状态不会影响其他客户端。

• 区别：原型模式是 “创建新对象”，但通过复制降低创建成本；享元模式是 “不创建新对象”，通过共享减少对象数量。

七、总结

享元模式是一种高效的对象复用设计模式，它通过分离对象的内部状态和外部状态，利用享元工厂和享元池来管理共享对象，从而达到减少对象数量、节省内存资源、提高系统性能的目的。在实际开发中，我们需要根据系统的需求和场景，合理判断是否使用享元模式，避免为了使用模式而增加系统的复杂度。

同时，在使用享元模式时，还需要注意内部状态和外部状态的划分、享元池的设计以及线程安全等问题，确保享元模式能够真正为系统带来性能上的优化。无论是文档处理系统、图形渲染系统，还是游戏开发、大数据处理等领域，享元模式都有着广泛的应用前景，是软件开发人员必须掌握的设计模式之一。