## 01、痛点

我是老李，去年在一家物流科技公司做车辆监控大屏。那天晚上八点，运维在群里说数据展示服务频繁 Full GC，页面卡成 PPT。

我们有一个车辆实时位置展示功能，最初只接入 2000 辆车。代码非常简单：从消息队列拉一批车辆状态，循环 new 出 VehicleMarker，设置车牌、经纬度、车辆类型、图标路径、颜色、尺寸、速度、方向等字段，然后推给前端。2000 个对象，JVM 轻松扛住。

后来业务扩展到 10 万辆，问题就来了。每个车辆点位都要创建一个完整 VehicleMarker，里面 icon、color、size 这些字段对同一车型是完全一样的，但还是在每个对象里复制了一份。10 万个对象不算多，但每个对象里还塞着字符串常量、样式对象、甚至小图标字节数组，内存直接被干到几百 MB，GC 压力巨大。

第一版代码差不多长这样：

```java
public class VehicleMarker {
    private String plateNo;
    private double lng;
    private double lat;
    private int speed;
    private String vehicleType;
    private String iconPath;   // 同一车型完全一样
    private String color;      // 同一车型完全一样
    private int iconSize;      // 同一车型完全一样
    // 构造器、getter、setter 一大堆
}
```

循环里每次都 new：

```java
for (Vehicle v : vehicles) {
    VehicleMarker marker = new VehicleMarker();
    marker.setPlateNo(v.getPlateNo());
    marker.setLng(v.getLng());
    marker.setLat(v.getLat());
    marker.setVehicleType(v.getType());
    marker.setIconPath(getIconPath(v.getType()));
    marker.setColor(getColor(v.getType()));
    marker.setIconSize(getSize(v.getType()));
    list.add(marker);
}
```

这个写法在 2000 辆时毫无问题，在 10 万辆时问题就非常具体：大量重复、细粒度的样式数据被复制了十万次。设计模式真正解决的，不是“代码写得不高级”，而是“变化开始失控”。这里变化不是业务分支失控，而是对象数量失控。

> 锐评：一个只有 2000 个对象、每台服务器内存 32G 的系统，你硬上享元模式，解决的不是内存问题，是上班时间没处花的问题。

## 02、是什么

享元模式的工程定义：当系统需要创建大量相似对象时，把可以共享的、不随场景变化的内部状态单独抽出来，用缓存复用；把随场景变化的外部状态留给调用方传递。

这听起来像“缓存”，但关键点在于状态拆分。

内部状态：可共享、相对稳定、不随调用场景变化。例如车辆类型的图标路径、颜色、尺寸。

外部状态：每个对象都不同，无法共享。例如车牌号、经纬度、速度、方向。

核心角色只有三个：

- Flyweight：享元接口，定义接收外部状态并完成业务动作的方法。
- ConcreteFlyweight：具体享元，持有内部状态，方法参数接收外部状态。
- FlyweightFactory：工厂，负责创建并缓存 Flyweight 对象，保证同类内部状态的对象只创建一次。

它们的关系可以画成：

```
Client --> FlyweightFactory --> Flyweight
              |                  ^
              +-- 缓存池 ---------+
              |                  |
              +-- ConcreteFlyweight
```

用 Java 已有的东西理解：String Pool 就是 JVM 对字符串的享元应用；Integer 在 -128~127 之间的缓存也是同一个思想。不是所有字符串都进池，而是那些会被反复使用的、不可变的部分才值得共享。

一句话判断入口：当你发现大量对象中有一部分字段完全相同，并且这些完全相同的数据占内存还不少，就该考虑享元了。

## 03、为什么

很多同学学过享元模式，但不会用，或者用错方向。常见三个误区：

误区一：对象多就是享元。对象多不一定是问题，对象多且差异小、重复数据多才是问题。如果每个对象的字段都不同，享元无法发挥价值。

误区二：以为所有对象都可以共享。享元共享的是内部状态，外部状态必须传参。很多人把整个对象塞进工厂缓存，结果缓存对象里的数据被不同线程改来改去，出现数据串车。

误区三：认为共享对象一定比新建对象好。共享对象要求内部状态不可变，否则需要加锁。加锁、防御性复制、缓存清理都会引入新的复杂度。

判断是否值得使用享元的几个标准：

1. 对象数量是否真的达到内存敏感量级？
2. 对象中是否存在大量相同、可提取的字段？
3. 这些相同字段在对象总大小中占比是否足够高？
4. 外部状态能否自然通过方法参数传入，而不需要改造成本太高？
5. 引入享元后，内存收益是否大于代码理解成本？

一个简单的判断公式可以写成：

模式收益 = 未来资源成本降低 - 当前抽象复杂度增加

它不是减少代码，而是降低大量重复对象带来的资源风险。

> 锐评：十辆车一个循环、每辆车一个对象，连 JVM 都不好意思喘气，这不是享元模式的机会，这是程序员太过勤快。

## 04、架构

享元模式解决的是“对象创建和内存管理”这一类问题。在开发问题地图里，它和工厂模式、对象池、缓存经常一起出现，但职责不同。

工厂模式：负责创建对象的逻辑。

对象池：复用一批固定对象，使用完归还，对象本身可变但生命周期受控。

缓存：保存昂贵数据，一般有淘汰策略。

享元：共享不可变的对象内部状态，外部状态由调用方传递。

结构上：

```
Client
  |
  | 获取共享对象
  v
FlyweightFactory
  |
  | 查缓存，没有则创建
  v
Flyweight
  ^
  |
ConcreteFlyweight
  |
  | 方法接收外部状态
  v
外部状态参数
```

变化识别流程：

```
需求变化
→ 对象数量急剧增长
→ 对象字段中大量相同
→ 区分内部状态 / 外部状态
→ 抽象 Flyweight 接口
→ 工厂缓存共享对象
→ 客户端传递外部状态
```

享元模式不是用来替代工厂模式，通常是工厂内部维护缓存。它也不是“全局单例”，同一个内部状态的对象可能只有一个，但享元对象本身没有业务状态，可以被多个调用方同时使用。

## 05、实战

这一节用上面那个车辆监控大屏完整重构。

### 一、业务场景

物流车辆监控大屏，10 万辆在途车辆实时展示。每辆车有车牌、经纬度、速度、方向、车辆类型、图标、颜色、尺寸等。同一车型的图标、颜色、尺寸完全一样，但车牌、位置不同。

### 二、第一版代码

第一版直接为每个车辆创建一个完整对象，字段全部复制：

```java
public class VehicleMarker {
    private String plateNo;
    private double lng;
    private double lat;
    private int speed;
    private String vehicleType;
    private String iconPath;
    private String color;
    private int iconSize;
    // 构造器和 getter/setter 省略
}
```

加载代码：

```java
List<VehicleMarker> markers = new ArrayList<>();
for (Vehicle v : vehicles) {
    VehicleMarker m = new VehicleMarker();
    m.setPlateNo(v.getPlateNo());
    m.setLng(v.getLng());
    m.setLat(v.getLat());
    m.setSpeed(v.getSpeed());
    m.setVehicleType(v.getType());
    m.setIconPath(getIconPath(v.getType()));
    m.setColor(getColor(v.getType()));
    m.setIconSize(getSize(v.getType()));
    markers.add(m);
}
```

### 三、代码开始失控

接入 10 万辆车后，样式字段 iconPath、color、iconSize 被复制 10 万次；峰值内存高、GC 频繁。更麻烦的是，如果图标路径规则变了，比如卡车图标从 png 换成 webp，不是只改一个地方，而是要重新生成所有 VehicleMarker。

### 四、模式重构

首先识别内部状态和外部状态。

内部状态：vehicleType、iconPath、color、iconSize。

外部状态：plateNo、lng、lat、speed。

定义享元接口：

```java
public interface VehicleStyle {
    String render(VehicleContext context);
}
```

VehicleContext 只保存外部状态：

```java
public class VehicleContext {
    private String plateNo;
    private double lng;
    private double lat;
    private int speed;
    // 省略构造器和 getter
}
```

具体享元实现，持有内部状态且不可变：

```java
public class TruckStyle implements VehicleStyle {
    private final String vehicleType = "truck";
    private final String iconPath = "/icons/truck.png";
    private final String color = "#FF6600";
    private final int iconSize = 32;

    @Override
    public String render(VehicleContext ctx) {
        return ctx.getPlateNo() + "," + ctx.getLng() + "," + ctx.getLat()
                + "," + vehicleType + "," + iconPath + "," + color + "," + iconSize;
    }
}
```

同样可以定义 CarStyle、VanStyle 等，为节省篇幅这里只写一个。

享元工厂：

```java
public class VehicleStyleFactory {
    private static final Map<String, VehicleStyle> CACHE = new ConcurrentHashMap<>();

    public static VehicleStyle getStyle(String type) {
        return CACHE.computeIfAbsent(type, t -> {
            switch (t) {
                case "truck": return new TruckStyle();
                case "car": return new CarStyle();
                case "van": return new VanStyle();
                default: throw new IllegalArgumentException("unknown vehicle type: " + t);
            }
        });
    }
}
```

调用方：

```java
List<String> rendered = new ArrayList<>();
for (Vehicle v : vehicles) {
    VehicleContext ctx = new VehicleContext(v.getPlateNo(), v.getLng(), v.getLat(), v.getSpeed());
    VehicleStyle style = VehicleStyleFactory.getStyle(v.getType());
    rendered.add(style.render(ctx));
}
```

为了验证资源收益，可以在工厂里加一个计数器。优化前，10 万个 VehicleMarker，样式对象创建次数 100000；优化后，样式对象创建次数等于车型数量，例如 3～12 个，外部状态 VehicleContext 仍然创建 10 万个，但它不持有图标、颜色、尺寸这些重复数据，总内存显著下降。

### 五、结构变化

改造前：

```
VehicleMarker
  |-- 车牌号、经纬度、速度
  |-- 车辆类型
  |-- 图标路径
  |-- 颜色
  |-- 尺寸
```

改造后：

```
VehicleStyle（共享）
  |-- 车辆类型
  |-- 图标路径
  |-- 颜色
  |-- 尺寸

VehicleContext（每个车辆一个）
  |-- 车牌号
  |-- 经纬度
  |-- 速度
```

调用关系：

```
RenderService
  |
  v
VehicleStyleFactory
  |
  +-- 缓存：卡车样式 / 轿车样式 / 面包车样式
  |
  v
VehicleStyle.render(VehicleContext)
```

### 六、收益

1. 样式对象创建数量从 10 万降到车型数量。
2. 重复的图标、颜色、尺寸不再复制到每个点位。
3. 修改某车型样式只需调整对应享元对象内部状态，不影响调用方逻辑。
4. 享元对象不可变，天然线程安全。
5. 更容易做单元测试，样式渲染逻辑和业务数据分离。

### 七、代价

1. 多出了接口、工厂、具体享元类，类数量增加。
2. 需要正确区分内部状态和外部状态，如果拆错了，反而把不该共享的数据共享了，会导致严重数据污染。
3. 外部状态通过方法参数传递，调用方需要维护上下文对象。
4. 工厂缓存如果没有上限，可能退化成全局大缓存；但车辆类型通常有限，这个问题不大。

### 八、什么时候不要用

1. 对象数量不大，比如几百上千，内存压力没有真实出现。
2. 对象中重复字段占比很低，抽出来也省不了多少内存。
3. 外部状态很难抽离，或者抽离后调用方改造成本远高于内存收益。
4. 内部状态可能频繁变化，导致共享对象频繁失效，维护缓存比新建还麻烦。

记忆口诀：

> 享元不是缓存所有对象，而是把“不随调用变化的部分”抽出来共享，把“随调用变化的部分”留在调用方。

> 锐评：如果车型只有两种，而且永远只有两种，每个车辆对象多占 20 字节，你非要抽象出三个接口六个类，那不是优化，是给维护的人上强度。

## 06、洞见

享元模式背后真正值得掌握的判断能力，比模式本身更重要。

洞见一：享元关注的是“共享稳定部分”，不是“减少对象数量”。减少对象数量只是结果，不是目标。目标是减少重复数据的复制。

洞见二：好的抽象通常来自真实资源压力，而不是提前设计。没有 10 万点位，你不会发现样式对象复制的价值。

洞见三：享元模式最重要的工程价值是降低批量数据的资源消耗，同时保证数据安全性。内部状态不可变是安全共享的前提。

洞见四：架构能力不是能上多少模式，而是知道什么时候不能共享。比如把车牌号当内部状态共享，就变成事故现场。

洞见五：Java 生态里到处都是享元思想。String Pool、Integer Cache、枚举单例、Spring 的 Bean 容器有些地方也体现了共享稳定对象的思路。数据库连接池虽然属于对象池，但核心也是复用昂贵资源，区别在于对象可变。理解这些区别，比背住 Flyweight 三个角色更有用。

> 锐评：初级开发者把代码写出来，高级开发者开始考虑对象能不能少建几个，架构师最终考虑的是：哪些对象根本不应该由业务代码创建。

## 07、行动

不要一上来就啃 GoF 23 种模式。先做享元这一种，把它用顺。

第一阶段：认识享元模式。

读懂本文实战章节，能说出内部状态、外部状态、工厂缓存的作用。

第二阶段：从自己的项目里找场景。

每天找一个可能对象数量很大的地方，例如：

- 批量报表导出里的单元格样式
- 消息模板渲染
- 地图点位/轨迹标记
- 字符、图标、元数据等

第三阶段：尝试重构，并回答五个问题。

1. 变化点是什么？
2. 哪些字段是内部状态，哪些是外部状态？
3. 不使用享元会怎样？
4. 引入享元增加了什么复杂度？
5. 下一次对象量级翻倍，需要修改几个地方？

七天实践计划：

Day 1：找一个业务里可能产生 1 万以上对象的循环。

Day 2：列出这个对象的字段，按“共享/不共享”分组。

Day 3：定义 Flyweight 接口和具体享元类。

Day 4：写 FlyweightFactory，加缓存和计数器。

Day 5：替换原有 new 对象逻辑，保证测试通过。

Day 6：用测试或 JVM 参数观察对象数量和内存变化。

Day 7：重新评估：如果对象量回到几百，这次重构是不是过度设计？

## 08、小结

金句：

> 享元模式不是让代码更“高级”，而是让 10 万个重复对象不再各搬各的砖。

享元模式解决的问题非常具体：大量相似对象导致资源消耗过高。它要求你区分内部状态和外部状态，把稳定且可共享的部分抽出来复用。真正值得学习的不是 Flyweight 这个单词，而是“共享稳定、传递变化”这种判断方式。

如果读完这篇文章，你在下一个批量处理场景里少创建了几万个重复对象，这篇文章就没有白写。

## 09、链接与概念说明

GoF 是什么：GoF 是 Gang of Four 的缩写，指《设计模式：可复用面向对象软件的基础》一书的四位作者。书中定义了 23 种经典设计模式。享元模式属于结构型模式。

创建型 / 结构型 / 行为型：

- 创建型：关注对象怎么创建，例如工厂、建造者、单例。
- 结构型：关注类或对象怎么组合成更大结构，例如适配器、装饰器、享元。
- 行为型：关注对象之间的职责和交互，例如策略、观察者、责任链。

SOLID 原则与享元模式的关系：

- 单一职责：享元对象只负责基于内部状态和外部状态渲染自身，业务对象负责记录动态数据。
- 开闭原则：新增车型只需新增一个具体享元类，并在工厂注册，通常不需要修改现有享元逻辑。
- 里氏替换原则：所有具体享元实现同一个 Flyweight 接口，可以互相替换。

享元模式和缓存的区别：缓存通常保存昂贵的计算结果或数据，可能有容量限制和淘汰策略；享元模式强调对象内部状态的共享复用，通常由工厂统一创建且生命周期与应用一致。

推荐继续阅读：

- 《设计模式：可复用面向对象软件的基础》，GoF 经典著作。
- 《Head First 设计模式》，更易入门。
- 《Effective Java》中关于不可变对象、对象创建和销毁的章节，对理解享元模式很有帮助。
- Java 官方文档中关于 String Pool 和 Integer 缓存的说明。

我是老李，去年在一家物流科技公司做车辆监控大屏。那天晚上八点，运维在群里说数据展示服务频繁 Full GC，页面卡成 PPT。

《设计模式军体拳第12招》 享元模式 Flyweight——共享对象降低系统资源消耗

车辆监控大屏 10 万点位的对象暴涨问题，用享元模式区分内部状态与外部状态，结合工厂缓存完成重构，并明确它带来的内存收益与使用边界。

架构师

编程语言

架构设计

后端

物流车辆监控大屏10万级数据量引发FullGC，通过享元模式提取车辆样式内部状态（图标、颜色、尺寸）复用，外部状态（车牌、经纬度）传参，将样式对象创建从10万次降至车型数，内存下降、GC压力缓解，含完整重构代码与实战判断标准。

数据库连接池

消息队列

数据安全

单元测试

内存管理

代码解释

数据库

服务器

容器

Java

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第12招》 享元模式 Flyweight——共享对象降低系统资源消耗-腾讯云开发者社区-腾讯云

《设计模式军体拳第12招》享元模式 Flyweight——共享对象降低系统资源消耗

《设计模式军体拳第12招》享元模式 Flyweight——共享对象降低系统资源消耗

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第12招》 享元模式 Flyweight——共享对象降低系统资源消耗

《设计模式军体拳第12招》 享元模式 Flyweight——共享对象降低系统资源消耗

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第12招》享元模式 Flyweight——共享对象降低系统资源消耗

《设计模式军体拳第12招》享元模式 Flyweight——共享对象降低系统资源消耗