C 里做高并发、实时渲染、大型服务端的同学大概率都遇到过同一个尴尬业务逻辑跑得挺顺一上规模内存就爆、创建对象就卡。前几年我做一个实时渲染工具时粒子数量从几千提到几万帧率直接跌到没法看排查下来发现根子不在算法而在对象数量。后来把核心效果数据抽出来做了共享内存和耗时都回到正常区间。这就是 C 中享元模式高级应用的价值用面向对象的共享复用去对付大规模、重复度极高的对象。这篇文章会从原理讲到实现再给三个比较有代表性的实战场景粒子系统、文本渲染、数据库客户端。适合正在写游戏、写服务端、做嵌入式或者在做数据库绑定的朋友参考。1. 先看本质享元模式到底在优化什么1.1 从内存账本看问题假设你有个最普通的粒子类class Particle { float x, y, z; // 位置 12B float vx, vy, vz; // 速度 12B float life; // 剩余生命 4B uint32_t color; // 颜色 4B Texture* tex; // 纹理指针 8B Shader* shader; // 着色器指针 8B Material material; // 材质参数假设 32B };这边加起来约80字节。1万粒子就是800KB10万粒子8MB100万粒子80MB。这还只是粒子自身占的空间。更麻烦的是当你开始逐个往 GPU 提交纹理和材质时大量重复的纹理切换、材质上传会让 CPU 和 GPU 驱动陷入状态切换泥潭。真相是那100万个粒子里绝大多数共享同一批纹理、shader、材质参数。火焰粒子用的纹理和材质永远来自那三五个特效模板。每个粒子都复制一份这些数据等于让每个人出门都背一整个文件柜而实际上只需要一张索引卡。生活化类比一张地图上有几千个公园标记每个标记不必背上完整公园的树种、门票价格、开放时间大家指着同一个地图数据集查询就行。1.2 内部状态与外部状态享元模式的灵魂享元模式把对象状态分成两类内部状态intrinsic state与具体实例无关、可以共享的状态。例如纹理ID、shader句柄、材质参数。这些特征是“模板级的”。外部状态extrinsic state随每个实例变化、必须由使用方自己保存和传入的状态。例如粒子坐标、速度、剩余生命。有一条设计红线必须记牢内部状态放进享元对象外部状态放在调用侧通过参数传给共享对象的方法。共享对象定义为不可变const是最稳妥的做法。这条线画清了整个模式就等于成了一半。相当多实现翻车都是因为外部状态被误塞进内部状态。后面会专门讲这类翻车现场。1.3 什么时候该用什么时候别用我不觉得每看到一个“对象很多”就要上享元。满足以下四个条件时享元才真正值得对象数量巨大至少万级起步十万、百万级效果更好对象之间存在大量重复的属性组合比如纹理shader材质只有几种组合共享部分的变化频率非常低模板数据基本不会中途改外部状态能干净地从对象里剥离不会牵一发动全身。反过来说如果对象只有几百个每个对象数据几乎都不同共享状态又天天变就不要硬上享元。我曾在一个项目里看到有人为了省几百KB内存给十几个配置对象建了一个工厂结果状态一改就要全局通知代码复杂度翻倍最后又拆回去。设计模式不是越多越好享元是典型的“选对了酸爽用错了反噬”。2. C实现的关键决策从经典骨架到线程安全工厂2.1 经典三件套与工厂的职责标准享元结构由三部分组成抽象享元、具体享元、享元工厂。先看抽象和具体部分// 抽象享元 class ParticleEffect { public: virtual ~ParticleEffect() default; virtual void render(const ParticleState external) const 0; }; // 具体享元内部状态全部const class EffectTemplate final : public ParticleEffect { public: EffectTemplate(std::string name, TextureID tex, ShaderHandle shader, Material mat) : name_(std::move(name)), tex_(tex), shader_(shader), material_(std::move(mat)) {} void render(const ParticleState external) const override; private: const std::string name_; const TextureID tex_; const ShaderHandle shader_; const Material material_; };具体享元里的字段都是const意味着创建后不可修改。这部分是我最想强调的实现细节。共享对象一旦允许写你根本无法保证某个线程不会顺手改掉别的粒子正在看的材质。C里没有JVM那种对象隔离所有共享数据都裸奔const是你能依赖的最廉价防线。工厂是享元和外界的中介。调用方不直接 new EffectTemplate而是向工厂要class EffectFactory { public: std::shared_ptrconst ParticleEffect get(const std::string key) { { std::shared_lockstd::shared_mutex lock(mutex_); auto it pool_.find(key); if (it ! pool_.end()) return it-second; } auto effect createEffect(key); std::unique_lockstd::shared_mutex writeLock(mutex_); auto result pool_.emplace(key, std::move(effect)); return result.first-second; } private: static std::shared_ptrconst ParticleEffect createEffect(const std::string key) { // 这里按key从资源系统加载纹理、shader、材质 return std::make_sharedEffectTemplate( key, loadTexture(key), loadShader(key), loadMaterial(key)); } std::shared_mutex mutex_; std::unordered_mapstd::string, std::shared_ptrconst ParticleEffect pool_; };get 的逻辑是标准的缓存查询命中直接返回未命中则加载创建并放入池中。这里用 shared_mutex 是为了让高频的“读缓存”操作并发进行加载写池时再加独占锁。2.2 单例工厂与线程安全的坑工厂本身不需要每个调用方各持一份通常做成单例。C11 之后有一个很省心的写法EffectFactory effectFactory() { static EffectFactory factory; return factory; }函数内部 static 变量初始化在 C11 标准下是线程安全的。很多老代码还在用双重检查锁DCLP手写单例除非你要兼容非常老的编译器否则真没必要。DCLP 在指令重排下容易出隐藏 bug而 magic static 由编译器保证初始化顺序省心得多。但“单例工厂”不等于“线程安全完成”。高并发下所有线程查同一个 unordered_mapshared_mutex 的读锁并发度不错可如果键值只有几十个、查询频率极高还可以考虑分片锁把 map 按 key 哈希分成 16 个 shard各 shard 独立锁。这个方案我在一个低延迟服务里试过效果很直接。另一个方向是 C20 的 std::jthread 配合无锁哈希表但复杂度会明显上升没有性能实测数据前不要盲目上。还有一个容易被面试官问到的误区单例模式不是享元模式。单例解决的是“全局只有一个实例”的问题享元解决的是“同一逻辑键共享同一个实例”的问题。用同一个键取享元得到同一个对象用不同键取到不同对象这跟单例完全是两种约束。2.3 用shared_ptr和weak_ptr管理享元生命周期池子必须回答“对象什么时候销毁”。最简单做法是池子持有 shared_ptr但这样池子永远不会释放不再使用的模板内存会缓慢膨胀尤其是动态加载的资源系统里键位会无限增长。我用过比较稳的组合外部使用方持有 shared_ptr池子只存 weak_ptr。class EffectFactory { public: std::shared_ptrconst ParticleEffect get(const std::string key) { { std::shared_lock lock(mutex_); auto it pool_.find(key); if (it ! pool_.end()) { if (auto shared it-second.lock()) { return shared; } // weak_ptr 已失效说明没有调用方再持有等待重建 } } auto effect createEffect(key); std::unique_lock lock(mutex_); pool_[key] effect; return effect; } private: std::shared_mutex mutex_; std::unordered_mapstd::string, std::weak_ptrconst ParticleEffect pool_; };这样粒子的生命周期由真正使用它的那些对象决定最后一个粒子释放模板自动销毁池子里的 weak_ptr 下一次查询时发现为空就重新加载。这比手动管理引用计数高一个层次也不会像 shared_ptr 长期驻留那样把池子变成泄漏池。如果资源本身很昂贵、重新加载成本高那就要反过来池子持有强引用再加上 LRU 淘汰或上限控制。比如池子超过 256 个模板时按“最后访问时间”淘汰。取舍依据很简单重新加载一次要花多少时间你愿不愿意为省一次加载多占点内存。3. 实战一粒子系统内存与帧率优化3.1 先算一笔账1万个粒子到底吃多少内存我拿一个简化但全面的粒子类来算位置、速度、生命、颜色这些“每个粒子各不相同”的字段大约 32 字节纹理指针、shader 指针、材质参数这些“特效模板级”字段大约 48 字节。不含模板字段时1 万粒子的内存是 0.32MB含模板字段时是 0.8MB。单独看好像差距不大但到 100 万粒子就变成 3.2MB 对比 8MB。如果材质参数再大一点比如带 PBR 参数集、动画曲线索引差距会更难看。更大的问题是创建耗时。每个粒子 new 出来时都要顺带“绑定纹理、上传材质”。材质上传是 GPU 驱动级别的操作一个粒子一次上传一万粒子就是一万次帧率不崩才怪。这里的瓶颈不是内存带宽而是驱动调用次数和状态切换次数。3.2 拆分效果模板与运动状态重构后的数据结构struct ParticleState { // 外部状态 float x, y, z; float vx, vy, vz; float life; uint32_t color; }; class ParticleSystem { struct Particle { ParticleState state; std::shared_ptrconst EffectTemplate effect; }; std::vectorParticle particles_; };所有粒子在初始化时只需从工厂取一次模板auto fire effectFactory().get(fire); for (size_t i 0; i count; i) { ParticleState s; s.x randomX(); s.y randomY(); s.z randomZ(); s.vx float(rand()) / RAND_MAX; s.vy ...; s.vz ...; s.life 1.0f; particles_.push_back({s, fire}); // 多个粒子共享同一个fire模板 }创建粒子的过程从“轻量级资源加载”变成了“几个 float 拷贝加一个 shared_ptr 拷贝”。1 万个粒子创建耗时通常能降到原来的五分之一到十分之一取决于原来的创建路径里有多少驱动调用。渲染循环也变得更合理按模板分组排序每次切换模板才设置一次纹理和材质 uniform然后提交这一组粒子的位置和颜色。外部的坐标数据本身不参与模板共享所以设置 uniform 时就是批量上传性能和可读性同时提升。3.3 优化效果对比给个我实测过数量的对比资料按常见游戏情景估列指标优化前优化后单粒子内存约80B约40B32B状态8B模板指针100万粒子内存约80MB约40MB另加3~5个模板创建1万粒子耗时包含纹理绑定/材质上传毫秒级纯内存拷贝微秒级渲染状态切换次数接近粒子数接近模板数最关键的变化是“渲染状态切换次数从粒子数坍缩到模板数”。很多引擎的渲染器都有 draw call 合并优化但前提是状态一致享元把状态一致这个问题从根本上解决了。注意粒子颜色放在外部状态里不参与共享这是刻意的。颜色是“我这个粒子的颜色”不是“这种效果的颜色”。如果某个特效确实需要所有粒子统一变色可以把它当作模板内部状态这时就出现了“模板热更新”问题要么做成不可变版本重建模板要么加锁保护。我的建议是尽量做成不可变宁可更新时重建模板也别让一个可变材质在渲染线程里裸奔。4. 实战二文本渲染中的字形图集复用4.1 重复字符与字体加载的浪费文本渲染是享元的另一个温床。一边滚动日志一边渲染 UI 时屏幕上可能有几千行文字每行都有“e”“a”“t”这种高频字符。如果每个字符实例都持有一个字体对象或者每次绘制都做一次字体加载和字形光栅化性能和内存都扛不住。字体文件本身很重一个 TTF 好几 MB光栅化出来的字形位图单个也要几百字节到上千字节。但字符集是有限集合常用的 ASCII 字符、常用汉字数量也就几千到几万。把“字符码点字号字体样式”作为键把字形位图作为共享值正好落在享元模式的射程内。这里的关键点是“键”要足够稳定字体样式、字号是共享维度字符位置、颜色、缩放是外部状态。千万别把位置塞进共享键里否则每移动一个字符都要创建一个新字形。4.2 GlyphAtlas缓存实现一个简化但可用的实现class GlyphAtlas { public: const Glyph* getGlyph(char32_t ch, float size) { std::string key glyphKey(ch, size); { std::shared_lock lock(mutex_); auto it cache_.find(key); if (it ! cache_.end()) return it-second.get(); } auto glyph rasterize(ch, size); // 光栅化耗时操作 std::unique_lock lock(mutex_); auto result cache_.emplace(std::move(key), std::move(glyph)); return result.first-second.get(); } private: std::string glyphKey(char32_t ch, float size) const { return std::to_string((uint64_t)ch) _ std::to_string(size); } std::shared_mutex mutex_; std::unordered_mapstd::string, std::unique_ptrGlyph cache_; };页面上一行日志的所有字符在渲染时都从同一个共享图集里取字形渲染位置坐标完全走外部参数不落在字形对象里。缓存不能无限膨胀。文本渲染场景和粒子系统不一样字形数量是动态的用户可能滚动日志翻到一整页生僻汉字。如果只存不淘汰内存会持续增长。实践上我推荐 LRU维护一个双向链表记录最近使用顺序配合 unordered_map 实现 O(1) 查找和淘汰。具体实现思路是用 std::list 存 keystd::unordered_map 存 key 到缓存项的迭代器每次命中把迭代器移到 list 头部超过容量就删除尾部和对应缓存项。很多游戏引擎里有现成的 LRUCache 模板直接抄即可。4.3 标准库string里隐藏的同类思路C 标准库里其实早就把类似理念用到了底层。std::string 的 SSOSmall String Optimization当字符串长度小于等于 15 字节常见实现时数据直接存在对象内部的栈缓冲上不分配堆内存。这样程序里大量解析短字符串、拼小段文本时就不会出现海量堆分配。这和享元模式不共享对象但共享了一个方向细粒度对象尽量少分配、多做复用。std::string_view 更是直截了当地告诉我们什么叫“只读共享”。它本身不拥有数据多个 string_view 可以指向同一段字符缓冲区只是各自的视角起始位置、长度不同。std::string logLine id2024 statusok; std::string_view idView(logLine.data() 3, 4); // 指向2024 std::string_view statusView(logLine.data() 12, 2); // 指向ok这跟享元的外部状态如出一辙底层数据共享使用方法各持一段视图。理解这个脉络后你会发现享元并不是什么偏门技巧它已经渗透在标准库和引擎设计的每个角落。5. 实战三数据库预编译语句与连接池中的享元思想5.1 预编译语句对象taos_stmt_prepare 与它背后的共享思路很多做数据接入的同学会忽略数据库客户端的预编译语句prepared statement就是享元模式。以时序数据库写入场景为例TDengine 的 C 绑定接口用taos_stmt_prepare先准备一条 SQL 语句模板之后循环执行时只需替换绑定参数TAOS_STMT* stmt nullptr; taos_stmt_prepare(conn, INSERT INTO ? USING meters TAGS(?) VALUES(?), stmt); for (size_t i 0; i rows.size(); i) { int tag rows[i].group; taos_stmt_set_tbname(stmt, rows[i].tableName); // 外部状态表名 taos_stmt_bind_param(stmt, 0, rows[i].ts); // 外部状态时间戳 taos_stmt_bind_param(stmt, 1, rows[i].value); // 外部状态测点值 taos_stmt_execute(stmt); taos_stmt_clear_bind(stmt); } taos_stmt_close(stmt);这里“prepare 出来的一条语句”内部持有解析后的 SQL 模板、绑定信息、甚至执行计划。每次 execute 只需要传入新的参数不需要重新做词法分析、语法分析、语义校验。这正是享元的经典结构准备好的语句作为内部状态复用参数作为外部状态每次变化。如果用字符串拼接方式每行都拼一条新 SQL 再执行高写入吞吐下 CPU 开销会明显上升而且在类似 TDengine 这种批量时序写入场景里预编译是性能收益最大的优化之一。其它数据库也一样MySQL 的 mysql_stmt_prepare、PostgreSQL 的 libpq prepared statement本质都是同一个设计思想。5.2 连接池是外部状态管理的教科书示范再看连接池。数据库连接对象本身可以被多个请求轮流复用但使用场景里的“当前事务”“会话变量”是独立于连接对象的。连接池从池中取出连接请求完毕后归还下一个请求取出同一物理连接继续用。这就是连接对象的共享。它和享元的差别在于连接对象不是存到 map 里按键复用而是放到队列里按“空闲状态”复用。从实现上看连接池通常需要配合 RAII 才能保证归还可靠class ConnectionPool { public: std::shared_ptrConnection get() { std::lock_guard lock(mutex_); if (idle_.empty()) { return createConnection(); } auto conn idle_.front(); idle_.pop(); return conn; } void release(const std::shared_ptrConnection conn) { std::lock_guard lock(mutex_); idle_.push(conn); // 注意这个版本用shared_ptr管理所有权真实项目里要注意并发归还的竞态 } };如果追求更严格的自动归还可以在 get 里返回一个代理对象析构时自动回到池中。这个模式在很多连接池库里叫“租约Lease模式”它的本质是把外部状态从共享对象里拆出来单独管理。5.3 享元不等于无脑共享连接的边界要划清楚说到这我必须泼一盆冷水连接对象可以复用不代表你可以把连接当成全局共享变量到处用。数据库连接带有会话状态事务是否开启、隔离级别、临时表、客户端编码等。两个线程同时拿到同一物理连接执行不同事务互相覆盖状态后果是灾难级的。正确的做法是“池化复用 会话隔离”连接从池中取出后先 reset 会话状态用完整体归还而不是让所有线程直接抢同一个连接。线程安全角度上如果业务模式非常固定用 thread_local 维护每线程一个连接也能绕过大部分锁竞争代价是连接数随线程数线性增长要按场景权衡。这段经验其实点明了享元模式的共同边界能够共享的一定是“与应用场景无关、不会互相覆盖”的资源。凡是带有会话状态、可变上下文的对象都不要试图做成全局共享的享元。6. 高频踩坑与排查技巧实录6.1 状态污染共享的内部状态被谁改了这是我见过最多的翻车场景。症状是改了 A 粒子的颜色结果所有粒子都跟着变。原因十有八九是有人把颜色、旋转、缩放这种明明属于外部状态的字段放进了共享模板的成员变量里甚至干脆把共享对象直接改写了。解决它的第一道防线是设计时就把共享对象字段设为 const对外不提供 setter。第二道防线是代码评审时留意任何“非 const 的共享成员”只要一个对象被扔进池子并且保存在 map 里它的所有可变字段都成了地雷。第三道防线是测试多线程环境下用 ASan 和 TSan 跑渲染循环状态污染往往会在数据竞争检测里暴露出来。6.2 生命周期事故缓存追着悬垂指针跑有段时间我接手过一个崩溃率很高的服务最后定位到是享元工厂返回裸指针而某个业务模块以为“这个对象归我管”顺手 delete 掉了。池子里的其他使用方继续用这个悬垂指针访问越界服务随机崩溃。这个问题的最佳解法就是全文反复强调的“池存 weak_ptr外部持 shared_ptr”。实在因为历史原因无法改造也至少要保证只有工厂负责销毁对象所有使用者只拿 const 引用或原始指针并且严格保证工厂生命周期长于所有使用方。这种三层生命周期约定很容易在重构时崩塌能用 shared_ptr 就不要用裸指针硬扛。6.3 命中率低与锁竞争工厂建好了cache 也加上了结果性能没提升反而因为锁竞争变慢。这种时候先看命中率。我在工厂里加过两个计数器hits 和 misses每次 get 都加一每隔一段时间打印一次。如果命中率低于 50%说明键粒度太细或者内部状态划分不合理。常见的原因是把实例 ID 也丢进了共享键比如“粒子ID纹理IDshaderID”当键等于每个粒子一个独立模板缓存反而变成额外开销。正确的做法是只保留真正稳定且数量少的共享维度比如纹理IDshaderID材质ID。如果键数量依然很大可以按访问频率做两级缓存热模板放无锁的 L1冷模板放带锁的 L2。锁竞争还有一个容易忽略的点单实例工厂的 shared_mutex 本身在高并发下也可能成为瓶颈。用分片锁把 map 按 hash 分段每把锁各自守护一片 key实测在 32 线程读多写少场景下能明显提升吞吐。6.4 排查工具内存膨胀和对象泄漏我习惯按这个顺序排查用 Heaptrack 跑一遍程序heaptrack ./app生成报告后用 heaptrack_gui 查看哪类对象数量最大、哪个调用栈分配最多一眼就能看清是不是某个共享模板被无限复制。用 Valgrind massif 看内存峰值valgrind --toolmassif ./app再用ms_print massif.out.*看分配热点适合长时间运行的守护进程。用 ASan 抓悬垂和越界编译时加-fsanitizeaddress跑一轮回归凡是生命周期问题基本都会暴露。用 perf 生成火焰图perf record -g ./app perf report关注有没有大量时间耗在构造函数、拷贝构造函数、分配器上如果构造函数自己成了热点大概率是对象没有走共享。这些工具都不需要改业务代码跑一次就能把“是不是享元没用对”变成数据结论省下大量猜谜时间。最后再分享一点个人体会享元模式高级应用的价值不在类图多漂亮而在能不能把“哪些数据可以共享、哪些数据必须私有”这条线画得足够干净。我这几年的习惯是共享数据一律 const 化、统一从工厂获取、配合 weak_ptr 控制生命周期发现大多数情况下收益都远超预期。另外一个小经验给每个享元对象塞一个调试用的 type_name 字段线上出问题时能快速定位某个异常模板是哪个 key 创建出来的这个习惯省了我很多查日志的时间。希望这些实践能帮到正在跟大规模对象死磕的同路人。