前段时间排查一个图形工具的性能问题现象很典型程序跑了一会儿内存从 300MB 一路涨到接近 2.8GB卡得鼠标都飘。把堆快照导出来一看将近 70% 的内存是一模一样的法线向量和纹理参数——同一个网格的几十万个顶点每个都背着完整的一套属性对象。这种场景教科书上管它叫享元模式Flyweight Pattern。但说实话教科书上那个“字符 字体格式”的例子根本不足以应对真实 C 工程里的内存、生命周期、并发压力。这篇文章想换个角度从实际重构经验出发聊 C 里享元模式那些不太初级但非常实用的玩法字符串驻留、数值区间共享、对象池组合、多线程获取最后用一个 2D 粒子系统完整拆一遍。适合已经理解设计模式基本概念、正在被内存或性能问题折磨的开发者。1. 先判断你的数据真的适合享元模式吗1.1 内在状态和外在状态到底谁该被共享很多人对享元的理解停留在“共享对象”四个字这是最大的误区。享元模式真正做的是把对象的属性拆成两类一类是独立于场景、不会变化的内在状态另一类是随使用位置变化的外在状态。共享的是前者转移出去的是后者。打个比方图书馆的书架是共享的每个读者不需要买一套《百科全书》放家里但每个人看哪一页、读到哪个词这个信息是私有的不能共享。书是内在状态页码是外在状态。所以在设计最开始不要先想“我怎么共享对象”而要先给对象的数据做一次体检哪些字段在生命周期内永远不变哪些字段只是逻辑上属于这个对象、实际上跟着上下文走如果发现一批对象里 80% 字段值重复这就是享元模式最典型的适用条件。1.2 C 为什么比 Java 更麻烦也比 Java 更合适在 Java 或 C# 里做享元最大的底气是垃圾回收。对象生命周期由 GC 托管共享对象没人用了自然被回收你几乎不用关心“谁拥有它、什么时候释放”。C 没有这个待遇一个裸指针被多个模块共享时必须自己解决所有权问题否则轻则内存泄漏重则悬挂指针。但也因为 C 有值语义、RAII、智能指针、constexpr享元可以做到比 GC 语言更“抠门”的程度。没有后台线程扫描没有停顿可以把共享数据直接放进内存池里用连续内存换缓存命中率。C 的麻烦C 的优势没有 GC生命周期要自己管RAII shared_ptr/weak_ptr 明确所有权值语义容易导致无意识拷贝引用语义只在显式声明时发生并发访问共享对象要加锁atomic/shared_mutex 可精细控制堆分配容易产生碎片内存池预分配分配开销可控1.3 判断阈值用数字说话很多团队把享元模式当“银弹”一谈性能就说要上享元结果花了几天改造收益微乎其微。我的习惯是先写个脚本统计一下候选对象的字段去重情况。核心是看三个数字重复字段占比如果某个字段的 unique 值数量 / 实例总数小于 1%收益最大对象数量级只有数量达到十万以上共享才有实际意义几千个对象省那么几个字节根本没有感知创建销毁频率如果对象在热路径上频繁创建销毁享元省下的不光是内存还有构造析构的时间。下面这个“去重收益估算”公式是我自己常用的节省内存 ≈ (字段大小 × 实例数) - (唯一值大小 索引/指针大小 × 实例数)如果算出来的结果小于实例数 × 4 字节基本不值得动。享元模式不是免费的它引入了表查找、并发控制、生命周期管理的额外成本省不下几个钱就没必要折腾。2. 字符串驻留池把重复字符串变成 O(1) 可比较的共享对象2.1 什么时候值得做字符串驻留C 标准库自带小字符串优化SSO在常见实现里十几个字节以内的短字符串直接存在对象内部不触发堆分配。所以短字符串之间复制代价很低不值得做驻留。真正要处理的是长字符串。比如从配置里读出来的路径、资源名、日志模板、协议字段名可能几百个字符。如果 10 万个对象每份都拷贝同一个路径字符串堆上就会存在 10 万份完全相同的数据内存和分配次数都很吓人。字符串驻留String Interning做的事情就是相同内容的字符串只保留一份其他地方复用指向它的智能指针。这个方案的好处有两个一是省内存二是比较 O(1)——如果共享保证是“同内容必同对象”那么直接比较指针地址就行不用逐字符 memcmp。2.2 线程安全驻留池实现与参数说明先给一个可用的“强引用驻留池”。它假设驻留的字符串在整个程序生命周期内都会反复用到不主动释放。#include memory #include mutex #include shared_mutex #include string #include string_view #include unordered_map class StringInternPool { public: std::shared_ptrconst std::string intern(std::string_view key) { std::shared_lockstd::shared_mutex read(mtx_); auto it map_.find(key); if (it ! map_.end()) { return it-second; // 已有相同字符串直接返回共享对象 } read.unlock(); std::unique_lockstd::shared_mutex write(mtx_); it map_.find(key); if (it ! map_.end()) { return it-second; // double-check防止两次插入 } auto shared std::make_sharedconst std::string(key); map_.emplace(*shared, shared); return shared; } private: std::unordered_mapstd::string, std::shared_ptrconst std::string map_; mutable std::shared_mutex mtx_; };几个细节要说明为什么用std::shared_ptrconst std::string共享对象必须不可变。一旦有人能修改所有引用它的地方都会被影响这比普通内存 bug 更难排查。为什么用std::shared_mutex驻留池是典型的“读多写少”结构。绝大多数intern调用在池里已经能找到目标只有首次插入才需要写锁。C17 之后用 shared_mutex 收益明显。为什么 double-check第一次查用共享锁没找到才升级写锁。在写锁里再查一次是为了防止两个线程同时发现 miss然后重复插入。哈希成本还在虽然比较字符串本身变成 O(1)但哈希还是要扫一遍字符串内容。如果字符串特别长可以考虑先用长度过滤甚至用更强的哈希缓存。2.3 引用的生命周期强引用池 vs 弱引用池强引用池有个副作用只要池还活着池里所有字符串永远不会释放。如果程序会持续产生新字符串池就会持续膨胀内存只增不减。弱引用池可以解决这个问题池里只存weak_ptr外部使用者持有shared_ptr。当最后一个使用者释放后字符串自动销毁下次再请求时重新创建。class WeakStringInternPool { public: std::shared_ptrconst std::string intern(std::string_view key) { { std::shared_lockstd::shared_mutex read(mtx_); auto it map_.find(key); if (it ! map_.end()) { if (auto sp it-second.lock()) { return sp; } } } std::unique_lockstd::shared_mutex write(mtx_); auto it map_.find(key); if (it ! map_.end()) { if (auto sp it-second.lock()) { return sp; } map_.erase(it); // 清理过期节点避免僵尸 key 堆积 } auto shared std::make_sharedconst std::string(key); map_.emplace(*shared, shared); return shared; } void clean_expired() { std::unique_lockstd::shared_mutex write(mtx_); for (auto it map_.begin(); it ! map_.end();) { if (it-second.expired()) it map_.erase(it); else it; } } private: std::unordered_mapstd::string, std::weak_ptrconst std::string map_; mutable std::shared_mutex mtx_; };注意上面这个实现里map 的 key 还是存了一份字符串副本。如果字符串很长、池长期保留大量 key这一份副本也不能忽略。更极致的做法是自定义哈希表的 key用string_view指向受控对象内部的字符串做到真正单副本。代价是哈希节点的生命周期管理更严格一旦 shared_ptr 释放对应的 key 就成了悬挂 view必须保证清理逻辑能及时擦除。工程上我建议先统计驻留池的命中率和字符串长度再决定要不要做单副本优化。3. 数值数据的区间共享比对象共享更狠的去重手段3.1 案例拆解法线和颜色数据重复对象共享只适合“整块对象完全相同”的场景。现实里更常见的是一张大数组里小片段高度重复但整体又不一样。举个例子。某个三维模型有 800 万个顶点每个顶点需要法线、切线、UV、颜色。法线和切线看起来像独立数据实际上模型表面大量平面区域的法线方向完全一致——可能 800 万个法线里只有 50 个不同的方向。常规做法是每个顶点保存一份完整法线向量复制 800 万次内存和带宽全浪费了。区间共享的做法是把唯一法线向量集中到一张表里每个顶点区域保存的是“这张表的区间索引”。引用同一个区间相当于共享一段时间内连续的法线数据。3.2 用 shared_ptr span 做只读区间切片C20 有std::span但它不拥有数据不适合直接保存到对象里——原数组被释放后 span 就悬垂了。更稳妥的方法是用shared_ptr持有底层数组再加上 offset 和 count 描述区间。template typename T class SharedSlice { public: SharedSlice(std::shared_ptrconst std::vectorT storage, size_t offset, size_t count) : storage_(std::move(storage)), offset_(offset), count_(count) {} const T at(size_t index) const { // 可以加边界检查release 版本去掉 return (*storage_)[offset_ index]; } size_t size() const { return count_; } private: std::shared_ptrconst std::vectorT storage_; size_t offset_; size_t count_; };每个顶点只需要保存一个SharedSliceglm::vec3真正占用内存的只有 shared_ptr16 字节左右 两个 size_t16 字节。而所有共享的顶点数据集中在一个大 vector 里缓存友好度比几千个独立对象高得多。如果你怕shared_ptr的引用计数操作有原子开销可以退一步把存储和引用分开外部用裸指针池生命周期用一个大shared_ptr统一管理。内部对象只存裸指针 区间省掉每次拷贝 shared_ptr 的原子计数。代价是约定所有切片都不能超过池的生命周期。3.3 和 SoA 结合后的巨大优势享元做到底之后再往前一步就是 SoAStruct of Arrays布局。传统对象池里一个 Particle 对象包含 color、position、velocity、texture_id内存布局是 AoS。改成 SoA 后所有粒子的 position 放在一个连续数组所有 velocity 放另一个连续数组依此类推。当“属性种类有限”时SoA 和享元会产生化学反应。比如粒子系统里只有 5 种基础粒子类型每种类型有独立的渲染参数。那么渲染循环里只需要按 type_id 把粒子的索引分桶同一类型的粒子用同一套渲染参数避免反复从 table 里取属性。这种写法本质上就是享元模式 数据导向设计在现代游戏引擎里非常流行老代码改造成这个样子后性能提升往往是数量级的。4. 内存池组合别让大量小享元对象把堆打成筛子4.1 大量 make_shared 的隐藏成本享元对象通常很小可能就是几十字节。但如果数量上百万每次make_shared都从全局堆分配内存会产生两个问题碎片化频繁申请释放相同大小的小块内存堆的空闲列表越来越碎分配速度下降后续大块连续内存申请困难原子操作开销shared_ptr 的引用计数是原子的每个对象单独管控在高并发场景下这是隐藏瓶颈。所以高级用法里享元对象经常和内存池绑定对象本身不直接new而是从一个预分配的连续缓冲区里“切”出来。对象死后内存归还池子复用。4.2 固定容量对象池实现与 shared_ptr 定制删除器下面是一个固定容量对象池的简单骨架用空闲链表管理槽位template typename T, size_t N class FixedObjectPool { public: FixedObjectPool() : free_count_(N) { for (size_t i 0; i N; i) { free_list_[i] i; } } template typename... Args T* acquire(Args... args) { std::lock_guardstd::mutex lock(mtx_); if (free_count_ 0) return nullptr; // 池满 size_t idx free_list_[--free_count_]; T* ptr reinterpret_castT*(storage_ idx * sizeof(T)); ::new (ptr) T(std::forwardArgs(args)...); return ptr; } void release(T* ptr) { std::lock_guardstd::mutex lock(mtx_); ptr-~T(); size_t idx (reinterpret_castchar*(ptr) - storage_) / sizeof(T); free_list_[free_count_] idx; } private: alignas(T) unsigned char storage_[sizeof(T) * N]; std::mutex mtx_; size_t free_list_[N]; size_t free_count_; };要和shared_ptr组合使用得自定义 deletertemplate typename T, size_t N std::shared_ptrT make_pooled_shared(FixedObjectPoolT, N pool, T value) { T* ptr pool.acquire(std::move(value)); if (ptr nullptr) return nullptr; return std::shared_ptrT(ptr, [pool](T* p) { pool.release(p); }); }注意构造 shared_ptr 的 lambda 捕获了 pool 的引用所以池的生命周期必须比任何使用它的 shared_ptr 都长。否则会出现释放内存时池已经销毁的幽灵问题这是这种写法最常见的翻车点。工程上最好把池做成一个全局单例或者放在更上层的生命周期管理对象里。4.3 实测观察碎片率和缓存命中率我在一个模拟项目里实测过直接make_sharedParticleType创建 100 万个对象堆碎片率在压力测试下能到 15% 以上换成固定对象池后碎片率基本归零分配吞吐因为连续内存分配比全局 new 快了不少。当然内存池不是银弹。池容量是固定的如果池满了 acquire 返回 nullptr你得有后备策略扩容、阻塞、或者临时落到全局分配。容量开太大预分配的内存又可能长期闲置。所以做之前一定要先量化对象峰值数量和对象大小。对比项全局 new/delete固定对象池分配耗时10万次较慢且不稳定极快基本是数组索引内存碎片明显无缓存命中率较低对象分散高内存连续实现复杂度不需要额外代码需要实现池和自定义 deleter生命周期风险由 shared_ptr 全权管理池必须先于所有对象死亡5. 并发安全多线程获取享元的思路与踩坑5.1 三种并发获取方案对比单线程的享元池很简单加不加锁都行。一旦进入多线程问题就来了多个线程同时请求同一个 key怎么保证只创建一个共享对象并且所有线程拿到同一个引用常用方案有三种方案思路优势劣势全局锁/共享锁整个池一把锁读多写少用 shared_mutex实现最简单正确性容易保证写路径所有线程互斥吞吐受限分片池按 key 哈希分到多个桶桶内独立锁并发度高实现难度中等同一个 key 的哈希冲突不可控极端倾斜时退化为单桶线程本地缓存每个线程先查本地miss 再查全局读路径几乎无锁不同线程之间不严格共享违背享元的“同内容同对象”保证实际工程里我首选分片池它在“实现简单”和“并发度”之间平衡得很好。线程本地缓存看起来美做起来坑很多跨线程比较时会遇到“内容相同但地址不同”的问题慎用。5.2 分片池以 key 哈希换并发度分片池的核心就是把原本一把锁的竞争摊到多把锁上template typename Key, typename Value, size_t Shards 16 class ShardedInternPool { public: Value get(const Key key) { Bucket bucket buckets_[std::hashKey{}(key) % Shards]; std::lock_guardstd::mutex lock(bucket.mtx); auto it bucket.map.find(key); if (it ! bucket.map.end()) { return it-second; } Value value make_value(key); bucket.map.emplace(key, value); return value; } private: struct Bucket { std::mutex mtx; std::unordered_mapKey, Value map; }; std::arrayBucket, Shards buckets_; };分片数一般取 2 的幂这样取模可以用位运算。但有个重要约束同一个 key 必须稳定映射到同一个分片不然就会出现“同一个 key 在两个桶各有一份对象”的问题既破坏享元语义又白占内存。哈希函数的选择很关键标准库std::hash对字符串表现还行对整数就可能是恒等映射——这时候如果 key 分布不均匀分片池和单锁没区别。5.3 并发场景的三个工程陷阱第一个陷阱是读锁里做耗时操作。我在驻留池代码里查找用的shared_lock只做哈希和红黑树/链表比较都是微秒级。但如果你在持锁状态下调用外部回调、写日志、重新哈希写者线程会活活饿死延迟直接炸掉。第二个陷阱是 double-check 的顺序写反。我看到有人先拿写锁发现不存在释放写锁再拿写锁插入中间那个窗口期另一个线程也拿到写锁并插入了同一份对象。正确做法是先读锁检查miss 后升级写锁写锁里二次检查再插入。第三个陷阱是std::shared_mutex的写者优先问题。C17 标准没有规定写者一定优先实现上可能出现“写者长时间等不到锁”的饥饿场景。高负载下如果观察到写者延迟异常就不要用 shared_mutex直接退回到普通 mutex或者给桶加一个等待队列。6. 完整重构案例一个 2D 粒子系统改造前后对比6.1 重构前每个粒子自己背全套属性假设有个小游戏 Demo里面跑 8 万颗粒子。老代码里 Particle 长这样struct Particle { // 内在状态几乎不会变 Color color; TextureId texture_id; BlendMode blend_mode; ShaderId shader_id; float mass; float drag_coefficient; // 外在状态每帧都在变 float x, y; float vx, vy; float life; };每粒子的颜色、纹理、混合模式、shader、质量、阻力系数其实只有 5 种组合但创建时每个粒子都完整复制一份。一次粒子系统启动就要写 6 个字段造出几十万个内容相同的对象内存和初始化时间全是浪费。更恶心的是光照贴图、序列化、网络同步时这些重复字段全都要带走协议包大了一圈。6.2 重构后类型共享 外部状态改造分两步。第一步把不变属性抽取为 ParticleTypestruct ParticleType { Color color; TextureId texture_id; BlendMode blend_mode; ShaderId shader_id; float mass; float drag_coefficient; }; struct Particle { uint32_t type_id; // 指向全局 ParticleType 表里的下标 float x, y; float vx, vy; float life; };第二步维护一个全局唯一的类型表创建粒子时只填 type_idstd::vectorParticleType particle_types; // 初始化后不再修改 Particle spawn_particle(uint32_t type_id, float x, float y, float vx, float vy, float life) { // 不需要拷贝任何 ParticleType 字段 return {type_id, x, y, vx, vy, life}; }6.3 改造完的数据对比和遗留问题在这个 Demo 上做了个简单对比项目重构前重构后单个 Particle 大小约 96 字节约 32 字节8 万粒子内存约 7.7MB约 2.6MB类型字段复制次数/帧8万 × 60是否需要堆分配每粒子多个字段可能触发堆分配无堆分配内存降了三分之一帧率提升主要来自缓存命中率改善——粒子数组在内存里更紧凑CPU 遍历起来更快。另外序列化也简单了网络上只需要传 type_id 状态量不用把 6 个冗余字段来回传。遗留问题很明确如果某个 ParticleType 的数据在运行时需要改动比如“把所有火粒子颜色调亮”改一张表就影响 3 万颗粒子这个很爽但如果某一颗粒子想单独特殊化比如“这一颗火粒子颜色要偏蓝”享元模式就帮不上忙了只能让粒子携带一个 optional 的覆盖字段。这也是享元模式的边界内部状态一但需要因人而异它就不再是内部状态了。7. 避坑速查享元模式最常见的几个问题定位7.1 生命周期悬挂引用和假共享共享对象最怕被释放后还有裸指针在飞。用 shared_ptr 能解决大部分问题但要注意“循环引用”和“跨池引用”。另一个坑是“假共享”两个对象内容相同但来自不同的享元池地址不一样。如果你的代码里有“地址相等 内容相等”的假设就会踩雷。要么保证全局只有一个池要么永远不依赖地址比较。7.2 内存只增不减强引用池如果不做淘汰长期运行必然膨胀。弱引用池如果只插入过期条目、不主动 erase也会堆积僵尸 key。定期调用clean_expired()、给池设置容量上限、或者用“按代重建”的策略都是可行的解法。我建议把驻留池的容量做成可观察的加一个简单的统计接口比如当前 key 数量、命中率、过期节点数。监控起来膨胀问题在早期就能发现不用等到 OOM 才排查。7.3 误共享可变状态放错位置最典型的错误是把“外在状态”塞进共享对象里。比如所有引用同一个 ParticleType 的粒子都能改 type 里的 color那改一个就全变了。定位办法很简单检查共享对象的所有字段在代码里搜索有没有对它赋值。有赋值就要考虑这个字段到底该不该共享。我在代码评审时经常问的问题就是“这字段谁写”如果超过一个字节的字段有写者它大概率就不是内部状态该迁出去。7.4 过度设计享元不是万能药享元模式本身有成本表查找、锁、生命周期管理、调试复杂度。如果你的对象只有几千个重复率不到 50%还真不如直接拷贝。机器内存现在也不便宜但开发时间去重更贵。我见过最离谱的改造是把一个只有 200 个对象的小配置系统硬套享元结果配置加载比原来慢了三倍。所以做之前先把第 1.3 节的估算公式跑一遍数据说话。最后说一点我个人的实操习惯。动手写享元之前我会先写一个几十行的脚本把所有候选对象的数据导出统计每个字段的 unique 值数量和实例总数的比。unique 占比低于 1% 的字段直接进共享表1% 到 5% 的要看访问频率再决定超过 50% 的碰都别碰。这个步骤花不了半小时但能挡住至少一半过度设计。另一个体会是享元池的边界往往就是项目里内存问题最隐蔽的位置每次改完都要用地址消毒器、堆快照工具跑一遍尤其在并发获取路径上别省这个时间。