享元模式：共享细粒度对象减少内存

FreeGuideOnline 最新 2026-06-18

享元模式

享元模式（Flyweight Pattern）是一种结构型设计模式，它通过共享细粒度对象来减少内存占用，提高系统性能。当应用中需要创建大量相似对象时，享元模式可以将这些对象中不变的部分抽取出来进行共享，从而避免重复创建相同的数据，节省宝贵的内存资源。

本教程将从实际场景出发，带你一步步理解享元模式的核心思想、结构与代码实现，并帮助你掌握它的适用场景。

目录

什么是享元模式？

享元模式的核心思想可以用一句话概括：共享可以重复利用的细粒度对象，从而减少系统中对象的总数，降低内存开销。

“享元”一词中的“享”取其“共享”之意，“元”则指那些最基础、最细小的单元对象。这些对象单独看起来微不足道，但当数量成千上万时，如果每次使用都新建一个实例，内存消耗将十分惊人。享元模式通过一个工厂来管理这些对象，确保同一个可共享对象只在内存中保留一份，并在需要时返回已有的实例。

为什么需要享元模式？

想象你正在开发一个包含地图的大型游戏，地图上有成千上万棵树。每棵树都有相同的种类、颜色和纹理，唯一不同的只是它们在地图上的位置和大小。如果不加设计地让每棵树都成为一个独立对象，内存中就会存储成千上万份完全相同的纹理数据，造成巨大浪费。

另一个典型场景是文本编辑器。一篇数十页的文档可能包含几万个字符，但字符的字体、大小、颜色等属性绝大部分是重复的。如果每个字符都持有自己的字体对象，内存开销将随字符数量线性增长，很容易导致性能问题。

这类场景的共同特征是：

  • 系统中存在大量对象。
  • 这些对象中有很多重复的内部数据。
  • 只有部分数据因上下文不同而发生变化。

享元模式正是针对这样的问题所提出的优雅解决方案。

模式结构与角色

享元模式包含以下几个核心角色：

  1. 享元接口（Flyweight）
    定义一个公共接口，通过该接口可以接收并作用于外部状态。

  2. 具体享元（Concrete Flyweight）
    实现享元接口，并为内部状态提供存储空间。具体享元对象必须是可共享的，它所封装的内部状态不会随环境变化。

  3. 非共享享元（Unshared Flyweight）
    并非所有抽象享元子类都需要被共享，有时一些对象以非共享的形式存在也很常见。这种角色在模式中并非必须。

  4. 享元工厂（Flyweight Factory）
    负责创建和管理享元对象。它维护一个享元池，当客户端请求某个享元时，工厂会先检查池中是否已有匹配的对象，有则直接返回，无则创建一个新的并放入池中。

  5. 客户端（Client）
    维护对享元对象的引用，并负责计算或存储享元对象的外部状态。

结构上最重要的是工厂对享元池的管理，以及内部状态与外部状态的分离。

关键概念：内部状态与外部状态

享元模式能够工作的前提是能够明确区分对象的 内部状态 和 外部状态。

  • 内部状态 是对象不变的那一部分数据，可以在不同场景下共享，它不依赖于具体的上下文环境。比如字符对象的字面字符、字体名称、字体大小（当它们相同时）；树对象的种类、纹理图片。
  • 外部状态 是对象可变、依赖于场景的那一部分数据，不能共享，必须由客户端在调用时传入。比如字符在屏幕上的坐标位置；树的种植坐标、缩放比例。

通过将内部状态抽离成可共享的享元对象，并把外部状态作为方法参数传入，同样的享元对象就可以在不同的上下文中重复使用。这样，系统中大量对象所占据的内存可以大幅缩减为极少数共享对象的内存。

代码实现（Java 示例）

我们用一个图形编辑器的例子来展示享元模式的实现。假设程序需要绘制成千上万个圆形，圆的颜色种类有限，但位置各不相同。

1. 定义享元接口

public interface Circle {
    void draw(int x, int y); // 外部状态通过参数传入
}

2. 实现具体享元

持有内部状态 color，该状态创建后不再改变。

public class ConcreteCircle implements Circle {
    private String color; // 内部状态

    public ConcreteCircle(String color) {
        this.color = color;
    }

    @Override
    public void draw(int x, int y) {
        System.out.println("绘制颜色为 " + color + " 的圆形，坐标(" + x + ", " + y + ")");
    }
}

3. 创建享元工厂

工厂内部使用一个 HashMap 作为享元池，保证相同颜色的圆只创建一次。

import java.util.HashMap;
import java.util.Map;

public class CircleFactory {
    private static final Map<String, Circle> circleMap = new HashMap<>();

    public static Circle getCircle(String color) {
        Circle circle = circleMap.get(color);
        if (circle == null) {
            circle = new ConcreteCircle(color);
            circleMap.put(color, circle);
            System.out.println("创建新圆形，颜色：" + color);
        }
        return circle;
    }
}

4. 客户端使用

客户端负责维护外部状态，并在需要时从工厂获取享元对象，然后调用方法传入外部状态。

public class FlyweightDemo {
    private static final String[] colors = {"红色", "绿色", "蓝色", "黄色"};

    public static void main(String[] args) {
        for (int i = 0; i < 20; i++) {
            // 随机选取一种颜色作为内部状态
            String color = colors[(int) (Math.random() * colors.length)];
            // 从工厂获取共享对象
            Circle circle = CircleFactory.getCircle(color);
            // 传入外部状态：随机坐标
            int x = (int) (Math.random() * 100);
            int y = (int) (Math.random() * 100);
            circle.draw(x, y);
        }
    }
}

运行这段代码你会发现，虽然循环中请求了 20 次圆形，但实际只创建了 4 个（对应 4 种颜色）。每个圆形对象都被重复使用，只是每次绘制时坐标不同。内存中对象的数量从 20 个降到了 4 个，效果十分明显。

享元模式的优缺点

优点

  1. 大幅降低内存开销
    共享可复用的内部状态，使得系统中对象的数量不再随使用场景的规模线性膨胀。

  2. 集中管理共享对象
    通过工厂统一创建和管理享元，避免了对象的随意创建，也方便进行统一优化和控制。

  3. 分离变化与不变
    促使设计者清晰地划分内部状态和外部状态，使代码结构更加清晰，维护性更好。

缺点

  1. 引入额外复杂度
    需要分离内外状态，创建工厂，对于简单场景而言可能过度设计，增加理解成本。

  2. 外部状态的管理负担
    客户端必须负责计算和维护外部状态，可能会让客户端代码变得复杂，且容易出现错误。

  3. 对线程安全的额外考量
    如果享元对象需要被多线程访问，必须保证内部状态的不可变性或做好同步处理，否则会引发数据不一致。

真实世界应用案例

文本编辑器的字模对象
在文字处理软件中，每个字符的字形数据（glyph）可以共享。比如一篇文档中有 10000 个字符 “A”，使用相同字体和字号时，内存中只需要存储一份 “A” 的字形对象，位置、颜色等作为外部状态动态传入。这极大降低了渲染引擎的内存负担。

游戏开发中的粒子系统
一个爆炸效果可能包含上千个粒子，它们的纹理、颜色变化曲线相同，但初始位置、速度、生命周期不同。享元模式可以让所有同类粒子共享纹理和颜色配置，每个粒子实例只持有自己的运动数据，从而支持屏幕上同时存在大量粒子而不会耗尽内存。

连接池与线程池
概念上的扩展——资源池同样应用了享元的思想。数据库连接池不会为每一次请求都创建新的连接，而是重复利用一组固定连接，将连接使用权的上下文（SQL 语句、参数）作为外部状态传入，从而减少连接的创建和销毁开销。

何时使用享元模式

在考虑是否应用享元模式时，可以对照以下条件：

  • 系统需要大量细粒度对象，且这些对象数量巨大，对内存造成了明显压力。
  • 对象的大量内部状态可以抽离成共享部分，且内部状态一旦创建就不应改变。
  • 外部状态相对独立，可以由客户端方便地计算或存储，并且可以在调用时传递给享元对象。
  • 对象身份不是核心关注点——即客户端不依赖于对象的唯一标识，多个客户端可以透明地共享同一个对象。

如果以上条件满足，则享元模式往往是值得采用的设计。反之，如果对象总数并不庞大，或者内外状态区分模糊，强行使用享元模式只会徒增复杂性。

总结

享元模式是一种通过共享对象来优化内存占用和性能的结构型设计模式。它巧妙地将对象的状态拆分为可共享的内部状态和不可共享的外部状态，并引入享元工厂对共享实例进行生命周期管理。

对于需要频繁创建大量相似对象的系统，享元模式能够显著减少对象数量、节约内存，同时让设计者清晰地梳理变化与不变的部分。当然，它带来了额外的设计复杂度和外部状态管理代价，因此需要根据实际场景权衡使用。

掌握享元模式的关键点在于理解 内外状态的分离 以及 工厂缓存机制。当你下次面对成百上千个“长得几乎一样”的对象时，不妨问问自己：“它们中不变的部分能否抽出来共享？” 这或许就能自然导向一个享元模式的优雅设计。