当前位置：首页 > news >正文

设计模式(C++)详解—享元模式(1)

news 2025/9/22 7:22:28

<摘要>
享元模式是一种结构型设计模式，其核心使命是通过共享技术来高效支持大量细粒度的对象，从而解决因对象数量爆炸性增长而导致的性能瓶颈（尤其是内存消耗）问题。该模式巧妙地将对象状态分解为“内在状态”（独立于场景、可共享）和“外在状态”（依赖于场景、不可共享）。通过建立一个享元工厂来管理共享的内在状态对象，并在需要时由客户端负责传递和维护外在状态，从而极大地减少了需要实际实例化的对象数量。享元模式是“池化技术”（如线程池、连接池）的理论基石之一，广泛应用于文本编辑器、游戏开发、图形系统以及任何需要管理大量相似对象的场景中。本文将从其背景概念、设计意图、UML剖析、C++实现细节、多个应用案例、到与数据库连接池的深度结合，进行一场约50000字的详尽探索。

1. 背景与核心概念

1.1 起源背景与发展历程

在软件开发的早期，面向对象编程（OOP）的“一切皆对象”思想极大地提升了代码的模块化和可维护性。然而，这种便利性有时会带来代价：当一个系统需要创建海量（数以万计甚至百万计）的细粒度对象时，巨大的内存开销和垃圾回收压力会成为系统性能的“不可承受之重”。

例如，在一个文字处理软件中，如果每个字符（如‘A’, ‘B’, ‘C’…）都用一个独立的对象来表示，那么一篇长篇文档将轻松创建数十万个字符对象。这些对象中，绝大部分的“字形”、“字体”、“大小”等属性是相同的（例如所有‘A’看起来都一样），只有“位置”、“颜色”（可能）等少数属性不同。为每个字符都完整存储所有这些信息，会造成巨大的内存浪费。

享元模式正是为了解决这一矛盾而诞生的。它最早由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides在1994年的开山之作《设计模式：可复用面向对象软件的基础》（俗称“GoF”书）中提出，并成为23种经典设计模式之一。其英文“Flyweight”意为“蝇量级”或“轻量级”，非常形象地表达了该模式的目标——让对象变得尽可能轻量。

现状趋势：如今，享元模式的思想已经深深融入各种编程语言和框架的基础设施中。最典型的体现就是各种“池”（Pool）技术：

数据库连接池：创建和销毁数据库连接是昂贵的操作。连接池在初始化时就创建一定数量的连接（享元对象），应用程序使用时只是从池中“借用”和“归还”，避免了频繁的创建销毁。
线程池：与连接池类似，通过复用线程来减少创建和销毁线程的开销。
字符串驻留（String Interning）：在许多语言（如Java、C#、Python）中，编译器或运行时会自动维护一个字符串常量池，相同的字符串字面量只会存在一份。
这些技术都可以看作是享元模式理念的延伸和规模化应用。

1.2 核心概念与关键术语

享元模式的成功关键在于对对象状态的清晰划分。

状态类型	描述	特点	示例（文字编辑器）
内在状态	对象固有的、独立于其运行场景的信息。这些信息使得一个对象可以被多个上下文共享。	可共享的、不变的	字符的字形、字体、大小。所有‘A’的这些信息都一样。
外在状态	对象依赖于其运行场景的信息。这些信息会随着上下文的变化而变化，因此不能被共享。	不可共享的、可变的	字符的位置（行、列）、颜色（在某些编辑器中）。每个‘A’的位置都不同。

享元模式的核心思想是：分离变与不变。将不变的内在状态抽取出来作为共享的享元对象（Flyweight Object），而将变化的外在状态剥离出来，由客户端代码在调用时传入。这样，系统只需要为每一种内在状态创建一个享元对象，然后通过传入不同的外在状态来“模拟”出大量不同的对象行为。

1.3 UML 类图解析

下面通过UML类图来清晰地展示享元模式的结构和各组件之间的协作关系。

角色说明：

Flyweight (享元抽象接口)
- 声明一个接口，通过该接口享元可以接收并作用于外在状态。operation(extrinsicState) 方法是关键，它接受外在状态作为参数。
ConcreteFlyweight (具体享元类)
- 实现享元接口。
- 为内部状态（内在状态）增加存储空间。该对象必须是可共享的。
- 其操作实现必须依赖于传入的外在状态。
UnsharedConcreteFlyweight (非共享具体享元类)
- 并非所有的Flyweight子类都需要被共享。该角色代表那些不需要共享的Flyweight对象。它同样由FlyweightFactory创建，但通常不存储在池中。客户端可以直接实例化并使用它。
FlyweightFactory (享元工厂)
- 创建并管理享元对象。
- 它维护一个“享元池”（Flyweight Pool），通常用一个字典或Map来实现（键是内在状态，值是享元对象）。
- 当客户端请求一个享元时，工厂会检查池中是否已存在具有相同内在状态的享元。如果存在，则直接返回；如果不存在，则创建一个新的享元，放入池中，然后返回。
Client (客户端)
- 维持一个对享元对象的引用。
- 计算或存储一个或多个外在状态。
- 在调用享元对象的操作时，需要将外在状态作为参数传递进去。

协作流程：

客户端从FlyweightFactory请求一个享元对象，并提供用于识别该享元的内在状态键（Key）。
工厂在池中查找。若找到，返回已存在的对象；若未找到，创建新对象，存入池中，然后返回。
客户端将外在状态传递给享元对象的操作方法（如operation(extrinsicState)）。

2. 设计意图与考量

2.1 核心目标

享元模式的设计意图非常明确且单一：运用共享技术有效地支持大量细粒度的对象。其终极目标是减少内存占用，提升性能。

减少对象数量：这是最直接的收益。系统内存中存在的对象数量从“与外在状态数量成正比”降低到“与内在状态种类数成正比”。在内在状态种类远少于外在状态数量的场景下（如字符，内在状态只有几十上百种，外在状态有数十万），内存节省是数量级的。
降低内存占用：每个对象实例本身都有对象头的开销（如C++的vptr，Java的对象头）。共享对象意味着大量节省这部分开销。
减少初始化开销：对于创建成本较高的对象（如数据库连接、线程），共享避免了重复的初始化过程。

2.2 设计理念与权衡

享元模式体现了几个重要的软件设计理念：

单一职责原则的扩展：它将对象的“存储职责”和“使用职责”进行了分离。享元对象只负责存储和处理内在状态，而外在状态的存储和管理职责则交给了客户端。这使得每个类的职责更加清晰。
以时间换空间：这是最经典的权衡。享元模式通过增加运行时的计算（客户端需要计算、存储和传递外在状态；工厂需要管理对象池并进行查找）来换取内存空间的极大节省。在内存稀缺或对象数量极大的情况下，这种交换是非常值得的。
接口隔离：享元接口强制要求操作必须接受外在状态参数，这定义了所有享元对象都必须遵守的契约，保证了系统行为的一致性。

2.3 实现上的考量与代价

天下没有免费的午餐，使用享元模式也需要付出一定的代价，并需要在实现时仔细考量：

运行时效率：每次操作都需要查找享元对象并传递外在状态，这会引入轻微的性能损耗。但对于节省的内存和GC开销而言，这点损耗通常可以忽略不计。
线程安全：享元工厂通常是多线程环境下的一个共享资源。getFlyweight()方法必须是线程安全的，否则可能导致创建出重复的享元对象。可以使用互斥锁（Mutex）等同步机制来保护工厂的内部状态（那个Map）。
外在状态的管理：客户端现在需要负责管理和计算外在状态。这增加了客户端的复杂性。如果外在状态本身也很复杂，可能需要引入新的辅助类来管理它们。
识别内在/外在状态：这是应用享元模式最困难的一步。必须仔细分析业务域，准确地将对象状态划分为内在和外在两部分。划分错误会导致共享失败或逻辑错误。

3. 实例与应用场景

3.1 案例一：文本编辑器中的字符对象

这是享元模式最经典的教科书式案例。

应用场景：一个文档包含成千上万个字符。
内在状态：字符的编码（如‘A’）、字体（如Arial）、大小（如12pt）、颜色（如果颜色是固定的，也可以是内在状态）。这些信息在所有相同格式的字符间共享。
外在状态：字符的位置（在第几行、第几列）。每个字符的位置都不同。
实现流程：
1. 定义一个Character享元类，其内在状态为charCode, font, size等。
2. 创建一个CharacterFactory，它以(charCode, font, size)为键来缓存已创建的字符享元对象。
3. 客户端（如文档渲染引擎）持有对Character对象的引用，并维护一个二维数组或其他结构来存储每个位置（外在状态）上应该显示哪个字符。
4. 渲染时，遍历所有位置，对于每个位置(x, y)，取出对应的Character享元对象和它的位置（外在状态），调用其draw(x, y)方法进行绘制。

C++ 代码简析：

// 享元类
class Character {
private:char m_charCode;std::string m_font;int m_size;// ... 其他内在状态public:Character(char code, const std::string& font, int size) : m_charCode(code), m_font(font), m_size(size) {}void draw(int positionX, int positionY) { // positionX, positionY 是外在状态// 绘制逻辑：使用内在状态(m_charCode, m_font, m_size)和外在状态(positionX, positionY)// 在(positionX, positionY)处绘制一个m_size大小的m_font字体的m_charCode字符std::cout << "Drawing '" << m_charCode << "' in " << m_font << " at (" << positionX << ", " << positionY << ")\n";}
};// 享元工厂
class CharacterFactory {
private:std::map<std::tuple<char, std::string, int>, Character*> m_charPool;public:Character* getCharacter(char code, const std::string& font, int size) {auto key = std::make_tuple(code, font, size);if (m_charPool.find(key) == m_charPool.end()) {m_charPool[key] = new Character(code, font, size);std::cout << "Creating new character: " << code << std::endl;}return m_charPool[key];}~CharacterFactory() {for (auto& pair : m_charPool) {delete pair.second;}}
};// 客户端使用
int main() {CharacterFactory factory;// 文档中有一万个字符'A'，但只创建一个享元对象Character* charA = factory.getCharacter('A', "Arial", 12);for (int i = 0; i < 10000; ++i) {charA->draw(i % 100, i / 100); // 传入不同的位置进行绘制}// 再使用一个不同的字符Character* charB = factory.getCharacter('B', "Arial", 12);charB->draw(50, 50);return 0;
}

3.2 案例二：游戏开发中的森林树木

在现代大型3D游戏中，渲染一个充满树木、岩石等自然元素的场景是常见需求。

应用场景：一个广阔的森林场景，需要渲染数万棵树木。
内在状态：树木的网格模型（顶点、法线、UV）、纹理（树皮、树叶）、Shader。这些数据非常庞大，但同一种树是完全一样的。
外在状态：树木的位置、朝向、缩放比例、LOD等级（Level of Detail）。每棵树这些状态都不同。
实现流程：
1. 定义一个TreeModel享元类，其内在状态为网格、纹理等渲染资源。
2. 创建一个TreeModelFactory来管理不同的树种（如橡树、松树）。
3. 客户端（游戏世界）维护一个列表，列表中每个元素存储一个对TreeModel享元的引用，以及该树实例的外在状态（变换矩阵等）。
4. 渲染循环中，遍历所有树木，对于每棵树，将它的外在状态（变换矩阵）设置到渲染管线，然后调用TreeModel->render()方法（该方法不需要参数，因为它所需的外在状态已通过渲染管线设置）。

这个案例是享元模式在图形学中的极致应用，是几乎所有游戏引擎和3D渲染软件的基础。

3.3 案例三：线程池/连接池

虽然池化技术的实现细节比基础的享元模式复杂，但其核心思想完全一致。

应用场景：Web服务器需要处理大量并发请求，每个请求都需要使用数据库连接。
“内在状态”：连接的建立方式（URL、用户名、密码等）。池里所有连接的这个信息都是一样的。
“外在状态”：连接的当前状态（空闲/繁忙）、被哪个线程持有、最后一次使用时间等。这些状态在连接被借出和归还时不断变化。
实现流程：
1. 连接池（ConnectionPool，即享元工厂）在初始化时，根据配置创建固定数量的连接对象（Connection，即享元对象）。这些连接在创建时就已经用“内在状态”（数据库配置）建立好了物理连接。
2. 当应用程序需要数据库连接时，它向连接池请求（getConnection()）。
3. 连接池找到一个当前状态为“空闲”（外在状态）的连接，将其状态标记为“繁忙”，然后返回给应用程序。
4. 应用程序使用完毕后，调用connection->close()（实际是归还给池子），连接池将其状态重新标记为“空闲”，以供其他请求使用。

池化技术将享元模式中的“外在状态由客户端管理”变成了“外在状态由池自己管理”，但其共享内在资源、减少创建销毁开销的核心思想是完全一致的。

4. 数据库连接池代码实现与解析

下面我们将实现一个简化版的C++数据库连接池，它深刻体现了享元模式的思想。

4.1 带完整注释的代码实现

注意：此实现为了聚焦于设计模式本身，进行了大量简化，省略了超时重连、心跳保活、事务处理等生产级特性。我们使用MySQL C Connector作为数据库驱动。

connection_pool.h

#ifndef CONNECTION_POOL_H
#define CONNECTION_POOL_H#include <stdio.h>
#include <list>
#include <mysql/mysql.h> // MySQL开发头文件
#include <error.h>
#include <string.h>
#include <iostream>
#include <string>
#include "../lock/locker.h" // 假设有一个封装了互斥锁和信号量的类/*** @brief 数据库连接池类* * 采用单例模式确保全局唯一，运用享元模式共享和管理数据库连接资源。* 通过信号量实现多线程环境下的连接获取和归还同步。*/
class connection_pool {
public:/*** @brief 获取连接池单例实例的静态方法* @return connection_pool* 连接池单例指针*/static connection_pool* GetInstance();/*** @brief 初始化数据库连接池* * 根据配置参数创建指定数量的数据库连接，初始化信号量，并设置最大连接数。* 该函数负责建立与MySQL数据库的物理连接，并将所有连接维护在连接池中备用。* * 输入变量说明：*   - url: 数据库主机地址，格式为IP地址或域名*   - User: 数据库用户名，用于身份认证*   - PassWord: 数据库密码，用于身份认证*   - DBName: 数据库名称，指定要连接的具体数据库*   - Port: 数据库端口号，MySQL默认端口为3306*   - MaxConn: 最大连接数量，决定连接池容量*   - close_log: 日志开关标志(0-开启，1-关闭)，影响日志输出行为* * 输出变量说明（设置类内成员）：*   - m_url: 保存数据库主机地址*   - m_Port: 保存数据库端口号*   - m_User: 保存数据库用户名*   - m_PassWord: 保存数据库密码*   - m_DatabaseName: 保存数据库名称*   - m_close_log: 保存日志开关状态*   - connList: 初始化后的数据库连接列表*   - m_FreeConn: 设置空闲连接数量*   - m_MaxConn: 设置最大连接数量*   - reserve: 初始化信号量，用于连接池资源管理* * 返回值说明：*   - true: 初始化成功*   - false: 初始化失败*/bool init(std::string url, std::string User, std::string PassWord, std::string DBName, int Port, int MaxConn, int close_log);/*** @brief 从连接池中获取一个可用连接* * 使用信号量进行P操作，等待可用连接。获取到连接后，从空闲链表取出，放入使用中链表。* * @return MYSQL* 指向MySQL连接对象的指针。如果获取失败返回NULL。*/MYSQL* GetConnection();/*** @brief 归还一个连接到连接池* * 将使用完毕的连接重新放回空闲链表，并执行V操作释放信号量。* * @param conn 要归还的MySQL连接对象指针* @return true: 归还成功* @return false: 归还失败（如连接为空）*/bool ReleaseConnection(MYSQL* conn);/*** @brief 获取当前连接池中空闲连接的数量* @return int 空闲连接数*/int GetFreeConn();/*** @brief 销毁连接池* * 遍历连接列表，关闭所有数据库连接，释放所有资源。*/void DestroyPool();private:// 构造函数私有化以实现单例connection_pool();~connection_pool();int m_MaxConn;          // 最大连接数int m_CurConn;          // 当前已使用的连接数int m_FreeConn;         // 当前空闲的连接数locker lock;            // 互斥锁，用于保护连接列表的并发访问sem reserve;            // 信号量，用于计数可用连接资源std::list<MYSQL*> connList; // 连接池（链表，存储所有连接的对象指针）// 数据库连接配置参数std::string m_url;std::string m_Port;std::string m_User;std::string m_PassWord;std::string m_DatabaseName;int m_close_log;        // 日志开关
};/*** @brief 连接池智能指针RAII包装类* * 在构造时从连接池获取连接，在析构时自动将连接归还给连接池。* 使用此包装类可以避免手动获取和归还连接可能导致的资源泄漏。*/
class connectionRAII {
public:/*** @brief 构造函数，自动获取一个连接* @param conn 输出参数，用于接收获取到的连接指针的地址* @param connPool 连接池实例指针*/connectionRAII(MYSQL** conn, connection_pool* connPool);/*** @brief 析构函数，自动归还连接*/~connectionRAII();private:MYSQL* conRAII;         // 持有的连接connection_pool* poolRAII; // 连接池引用
};#endif

connection_pool.cpp

#include "connection_pool.h"// 懒汉式单例模式初始化
connection_pool* connection_pool::GetInstance() {static connection_pool connPool; // C++11保证局部静态变量线程安全return &connPool;
}// 构造函数初始化成员
connection_pool::connection_pool() : m_MaxConn(0), m_CurConn(0), m_FreeConn(0) {}// 初始化连接池
bool connection_pool::init(std::string url, std::string User, std::string PassWord, std::string DBName, int Port, int MaxConn, int close_log) {// 1. 保存配置参数（享元的“内在状态”）m_url = url;m_User = User;m_PassWord = PassWord;m_DatabaseName = DBName;m_Port = Port;m_close_log = close_log;m_MaxConn = MaxConn;// 2. 创建MaxConn个数据库连接for (int i = 0; i < MaxConn; i++) {MYSQL* con = NULL;con = mysql_init(con); // 初始化MYSQL句柄if (con == NULL) {LOG_ERROR("MySQL Error: mysql_init() failed"); // 假设有日志宏exit(1);}// 建立实际物理连接（使用内在状态参数）con = mysql_real_connect(con, url.c_str(), User.c_str(), PassWord.c_str(), DBName.c_str(), Port, NULL, 0);if (con == NULL) {LOG_ERROR("MySQL Error: mysql_real_connect() failed: %s", mysql_error(con));exit(1);}// 3. 将创建好的连接加入连接池链表connList.push_back(con);++m_FreeConn; // 空闲连接数增加}// 4. 初始化信号量，初始值设为空闲连接数（即可用资源数）reserve = sem(m_FreeConn); // 假设sem类的构造函数接受初始值m_MaxConn = m_FreeConn; // 最大连接数即初始创建的数量return true;
}// 从连接池获取连接
MYSQL* connection_pool::GetConnection() {MYSQL* con = NULL;if (connList.size() == 0) {return NULL;}reserve.wait(); // P操作，等待信号量（申请资源）lock.lock(); // 加锁，保护共享资源connListcon = connList.front(); // 从链表头部取出一个连接connList.pop_front();--m_FreeConn; // 空闲连接数减1++m_CurConn;  // 已使用连接数加1lock.unlock(); // 解锁return con;
}// 归还连接到连接池
bool connection_pool::ReleaseConnection(MYSQL* con) {if (con == NULL) {return false;}lock.lock(); // 加锁// 将连接重新放回链表尾部connList.push_back(con);++m_FreeConn;--m_CurConn;lock.unlock(); reserve.post(); // V操作，释放信号量（释放资源）return true;
}// 销毁连接池
void connection_pool::DestroyPool() {lock.lock();if (connList.size() > 0) {// 遍历连接列表，关闭所有数据库连接for (auto it = connList.begin(); it != connList.end(); ++it) {MYSQL* con = *it;mysql_close(con);}m_CurConn = 0;m_FreeConn = 0;connList.clear(); // 清空链表}lock.unlock();
}// 析构函数
connection_pool::~connection_pool() {DestroyPool();
}// ----------- connectionRAII 类的实现 -----------
connectionRAII::connectionRAII(MYSQL** SQL, connection_pool* connPool) {*SQL = connPool->GetConnection(); // 从池中获取连接conRAII = *SQL;poolRAII = connPool;
}connectionRAII::~connectionRAII() {poolRAII->ReleaseConnection(conRAII); // 析构时自动归还
}

4.2 Mermaid 流程图与时序图

连接池初始化流程图

获取与归还连接时序图

4.3 Makefile 范例及编译运行

假设项目结构如下：

your_project/
├── bin/            (目标二进制文件目录)
├── build/          (编译中间文件目录)
├── include/        (头文件目录)
│   ├── connection_pool.h
│   └── locker.h    (假设的锁封装头文件)
├── src/            (源文件目录)
│   ├── connection_pool.cpp
│   └── main.cpp    (测试主程序)
└── Makefile

Makefile:

# Compiler and flags
CXX := g++
CXXFLAGS := -Wall -Wextra -g -std=c++11 -I./include
LDFLAGS := -L/usr/lib64/mysql -lmysqlclient -lpthread# Directories
SRC_DIR := src
BUILD_DIR := build
BIN_DIR := bin# Targets
TARGET := $(BIN_DIR)/test_conn_pool
SRCS := $(wildcard $(SRC_DIR)/*.cpp)
OBJS := $(SRCS:$(SRC_DIR)/%.cpp=$(BUILD_DIR)/%.o)# Default target
all: $(TARGET)# Link the target executable
$(TARGET): $(OBJS) | $(BIN_DIR)$(CXX) $(OBJS) -o $@ $(LDFLAGS)# Compile source files to object files
$(BUILD_DIR)/%.o: $(SRC_DIR)/%.cpp | $(BUILD_DIR)$(CXX) $(CXXFLAGS) -c $< -o $@# Create directories if they don't exist
$(BIN_DIR):mkdir -p $@
$(BUILD_DIR):mkdir -p $@# Clean up build artifacts
clean:rm -rf $(BUILD_DIR) $(BIN_DIR)# Phony targets
.PHONY: all clean

编译方法：

确保系统已安装 MySQL C Connector 开发库（例如在 Ubuntu 上：sudo apt-get install libmysqlclient-dev）。
在项目根目录下终端中执行 make 命令。
编译成功后，可执行文件将生成在 bin/test_conn_pool。

运行方式：

确保 MySQL 服务器正在运行，并且配置参数（URL, User, Password, DBName）正确。
在终端中运行：./bin/test_conn_pool。

结果解读：
你需要编写一个 main.cpp 来测试连接池。一个简单的测试可能包括：

初始化连接池。
创建多个线程，每个线程都从池中获取连接，执行一个简单的查询（如 SELECT 1;），然后归还连接。
观察程序输出，确认连接被成功共享和复用，而没有发生创建超过 MaxConn 数量的连接。

如果程序正常运行并完成所有查询，则证明连接池工作正常。如果出现连接错误或死锁，则需要检查代码逻辑和线程同步机制。

5. 交互性内容解析

数据库连接池本身是一个多线程环境下的共享资源管理器，其交互核心是线程同步。

同步机制：我们使用了互斥锁（Mutex） 和信号量（Semaphore）。
- 互斥锁 (locker)：用于保护对共享容器 connList 的访问。GetConnection() 和 ReleaseConnection() 中对 connList 的 push 和 pop 操作必须在锁内进行，以防止多个线程同时修改链表导致其状态不一致（数据竞争）。
- 信号量 (reserve)：用于计数可用连接资源。其初始值等于最大连接数。GetConnection() 中的 wait()（P操作）会消耗一个信号量，如果信号量为0，线程会阻塞等待。ReleaseConnection() 中的 post()（V操作）会增加一个信号量，并唤醒一个等待的线程。这确保了发出的连接数永远不会超过池的总容量。
RAII技术：connectionRAII 类是一个重要的交互辅助工具。它利用C++的RAII（Resource Acquisition Is Initialization）特性，在构造函数中获取资源（连接），在析构函数中释放资源（归还连接）。这确保了即使在发生异常的情况下，连接也能被安全地归还给池子，避免了资源泄漏。这对客户端代码来说是非常友好的，它简化了“获取-使用-归还”的流程。