游戏引擎卡成PPT的时候我盯着内存监控器里的数字半天没说话。23000个爆炸粒子每个都自带一份完整的纹理贴图和网格数据16GB内存直接被吃掉了2.7GB帧率掉到11。后来我重构成享元模式同样的效果多线程下同时生成60000个粒子还开垂直同步内存占用掉到原来的十分之一。这次我打算把踩过的坑、改完之后的代码、还有怎么判断一个对象到底适不适合做享元全部摊开来讲。这篇就算是我自己复盘C享元模式从理论到落地的一份完整记录。1. 为什么要折腾享元模式内存爆炸现场复盘1.1 那个让我被迫重构的真实场景项目是个大逃杀手游的原型DEMO战斗系统里每个爆炸点会产生800到1500个子粒子一轮团战打起来同时存活的粒子数经常破三万。最初版本非常朴实每个粒子都是一个完整对象构造函数里传纹理路径、网格标识、颜色、默认尺寸然后把它们全部存到vector里。问题在粒子数量过5000之后开始显现。每个粒子对象里纹理是一个std::string存的是assets/textures/fireball_01.png这种完整路径真实解析到显存之后还有对应的资源句柄。如果每个粒子对象都持有自己那份纹理数据和网格数据哪怕底层资源是同一份贴图内存里也会堆出几万份重复的字符串、句柄和状态拷贝。我记得很清楚压测到26000个粒子时任务管理器里内存曲线直接陡增。那会还拖着调试器跑profiler显示内存分配热点就集中在粒子构造函数里——每new一个粒子就要深拷贝一次纹理字符串底层SDK为了安全性还会再拷贝一次资源句柄。26000个粒子等于26000份重复的assets/textures/fireball_01.png每份几十字节加上26000份网格数据每份几KB这一下就是几百MB的纯垃圾。1.2 享元模式解决的核心矛盾共享与独立的纠缠享元模式Flyweight Pattern的出发点很简单把对象属性拆成两类。一类叫内部状态Intrinsic State这一类数据是多个对象共用的、不会随着个体变化的另一类叫外部状态Extrinsic State是每个实例自己特有的、会变的。在粒子这个场景里纹理路径、网格标识、默认大小属于内部状态因为它们对所有同类型粒子来说完全一样。而位置、速度、剩余生命周期属于外部状态每个粒子各不相同爆炸出来那一瞬间的飞散速度都不一样。你可以把享元模式理解成图书馆里编目卡片和借书记录的关系。某本小说的书号、书名、出版社信息是内部状态这张卡只有一张放在目录柜里大家共用。谁借了书、什么时候还是外部状态记在借阅记录里每个读者单独一条。图书馆不可能给每位读者都复印一本完整的书目信息那会疯掉的。游戏引擎里也一样不应该让每个粒子都抱着一整份纹理数据到处跑。1.3 为什么C里特别值得做这件事C的内存管理模型决定了每个对象自足的做法代价格外高昂。每个对象内的std::string如果独立构造每一次都是堆分配每个集合对象又意味着额外的迭代器开销和缓存不友好。当几万个同类对象存在时这种重复不是浪费一点内存的问题而是会直接拖垮CPU缓存命中率。在Java或者C#里也有享元模式但C的差异在于我们可以把内部状态设计成const对象用const指针或const引用去共享它。编译器可以对这种共享做激进优化配合std::string_view、span等视图类型共享成本会进一步降低。更重要的是C里我们可以精确控制对象的生命周期和存储位置用智能指针配合工厂模式把享元对象的创建和释放都收拢到一个统一的地方这比垃圾回收语言里对象池被GC扫掉的行为可预测得多。2. 先从设计层面把角色理清楚2.1 享元模式的三个核心角色一个标准的享元模式实现里有且只有三个角色享元接口、具体享元类、享元工厂。有些资料还会把客户端单独列出来但客户端不参与模式结构设计它只是使用方。享元接口定义的是对内部状态的操作。具体享元类实现接口同时存储内部状态并且保证内部状态不能被修改要么通过const方法暴露要么把成员设成const。享元工厂是整个模式的关隘负责维护一张享元对象缓存表通过键值查表决定返回已有对象还是创建新对象。带代码看会更直白。我先定义一个最简洁的接口层class ParticleType { public: virtual ~ParticleType() default; virtual void draw(float x, float y, float size) const 0; };然后实现具体享元类class FireParticleType : public ParticleType { public: FireParticleType(std::string texturePath, int meshId, float baseSize) : texturePath_(std::move(texturePath)), meshId_(meshId), baseSize_(baseSize) {} void draw(float x, float y, float size) const override { // 这里走渲染管线纹理和网格ID被传进去 // renderer-draw(texturePath_, meshId_, x, y, size); } private: std::string texturePath_; // 内部状态 int meshId_; // 内部状态 float baseSize_; // 内部状态 };这个类就是共享的部分。整个游戏运行期间同一种火焰粒子类型只需要创建一份实例无论它被几千个粒子同时引用。2.2 工厂的键设计用什么来区分同一类工厂的职责是保证同一种类型的享元对象全局只有一个。它内部维护一个查找表最常见的是std::unordered_map。键的选择需要认真考虑键必须是能够唯一确定一组内部状态的字段组合。我一开始用的是纹理路径加网格ID拼接成的字符串。这种方案有个致命问题不同粒子类型的baseSize如果不同纹理和网格相同的话这个键会串台。后面我改成用内部状态的全部字段做键统一封装成一个结构体这样才准确。struct ParticleTypeKey { std::string texturePath; int meshId; float baseSize; bool operator(const ParticleTypeKey) const default; }; struct ParticleTypeHash { size_t operator()(const ParticleTypeKey key) const { size_t h1 std::hashstd::string()(key.texturePath); size_t h2 std::hashint()(key.meshId); size_t h3 std::hashfloat()(key.baseSize); return h1 ^ (h2 1) ^ (h3 2); } }; class ParticleTypeFactory { public: std::shared_ptrconst ParticleType get(ParticleTypeKey key) { auto it cache_.find(key); if (it ! cache_.end()) { return it-second; } auto type std::make_sharedconst FireParticleType( key.texturePath, key.meshId, key.baseSize); cache_.emplace(std::move(key), type); return type; } private: std::unordered_mapParticleTypeKey, std::shared_ptrconst ParticleType, ParticleTypeHash cache_; };返回类型用shared_ptr 而不是普通shared_ptr含义很明确拿到手的东西不能乱改。享元对象一旦创建就不可变所有客户端只能通过它的const接口读取内部状态这样即使多线程同时拿同一个享元也不会出现数据竞争。2.3 外部状态怎么设计不要把共享和独立的边界画错了很多初学者问我外部状态就是另开一个结构体存位置、速度不就完事了吗确实基础的分离很简单但边界画错的坑并不在数据分离那步而是在哪些字段算内部、哪些算外部的判断上。判断标准我总结成一句如果这个字段的值在所有同类对象之间完全相同并且不会在对象的生命周期中改变那它适合做内部状态。如果这个字段每个对象都不一样或者存在我这个粒子飞了一半突然变了颜色这种情况它就必须放外部状态。颜色在我那个场景里就吃了个教训。最初我把颜色也做成内部状态因为爆炸粒子都是橙红色。后来美术在分帧调色板方案里给粒子加了渐变色每个粒子发射出来后的几秒内颜色从亮橙变成暗棕。这个时候颜色就从内部状态变成了外部状态你得把它从ParticleType里拿出来放到粒子的个体数据里。所以做设计的时候别以为内部状态永久不变就是真理业务需求一变边界就要跟着移动架构上要给这种移动留好余地。3. 实战实现从粒子系统到文本编辑器两种案例3.1 案例一万人同屏粒子系统的重构这个案例就是我在1.1节说的爆炸粒子系统重构。改造前的粒子类长这样class ParticleBefore { public: ParticleBefore(std::string texture, int meshId, float x, float y, float vx, float vy, float lifetime) : texture_(std::move(texture)), meshId_(meshId), x_(x), y_(y), vx_(vx), vy_(vy), lifetime_(lifetime) {} void update(float dt) { /* 更新位置、速度、生命周期 */ } void draw() const { // renderer-draw(texture_, meshId_, x_, y_, defaultSize_); } private: std::string texture_; // 重复存储 int meshId_; // 重复存储 float defaultSize_; // 重复存储 float x_, y_; // 外部状态 float vx_, vy_; // 外部状态 float lifetime_; // 外部状态 };重构后内部状态被单独抽到ParticleType里外部状态则集成为一个Particle实例class Particle { public: Particle(std::shared_ptrconst ParticleType type, float x, float y, float vx, float vy, float lifetime) : type_(std::move(type)), x_(x), y_(y), vx_(vx), vy_(vy), lifetime_(lifetime) {} void update(float dt) { x_ vx_ * dt; y_ vy_ * dt; lifetime_ - dt; } void draw() const { type_-draw(x_, y_, 1.0f); } private: std::shared_ptrconst ParticleType type_; float x_, y_, vx_, vy_, lifetime_; };注意这里type_用的是shared_ptr 这表示粒子持有的是共享类型的引用但不可改。数据流变成了粒子个体对象持有享元指针自身坐标速度彻底把共享和独立分开了。内存收益可以直接算一笔账。假设纹理路径平均60字节、网格ID是4字节、默认尺寸是4字节加上指针等开销改造前每个粒子的重复字段大约68字节再加上std::string内部堆分配的开销又22字节以上重复存储带来的额外成本接近每粒子90字节。10000个粒子仅这一项就浪费了接近900KB。而享元模式下同类型的所有粒子共享同一个ParticleType这部分内存只付一次。这个900KB放在今天动辄几十GB的游戏资产面前不算什么巨款但它只是最直观的收益。真正的优势在别处缓存友好度、创建开销、对象池的整合能力。因为粒子个体对象里只剩指针加上干巴巴的几十字节坐标速度所有粒子数据在vector里排得紧凑极了CPU缓存命中率高了一个数量级这才是帧率起飞的关键。3.2 案例二文本编辑器里的字符渲染游戏粒子系统是最典型的案例但享元模式在文本渲染中同样经典。文本编辑器的Document可能包含几万行文本渲染时每个字符如果都要存储字体、颜色、字体大小、字重这些属性内存上的浪费同样是天文数字。文本渲染的享元结构是FontStyle类作为享元存储字体大小、行高、字重、颜色等共享属性CharacterRun作为外部属性存储具体的字符串序列和范围。同一个FontStyle可以被全文档几十处地方引用每一处只存一个指针和字符区间。这个案例里我特别想强调一点很多文章提享元模式都会说日志系统和字符串常量池其实文本编辑器里这个玩法才是接地气的。你去实现一个富文本控件每段落都重复创建一份Font对象时间一长你自己都能闻出内存泄漏味。用享元模式把Font做成缓存复杂度并没有增加多少但内存占用、比较速度、序列化时的索引转换都会顺滑很多。3.3 完整工厂实现统一管理和懒加载工厂采用懒加载策略也就是第一次访问到某个键时才创建对应享元之后再请求直接复用。这个策略的好处是启动阶段不会一股脑把全部类型都构建出来只有实际用到的类型才会进入缓存表。class ParticleFactory { public: std::shared_ptrconst ParticleType get(int meshId, float baseSize) { auto key std::make_pair(meshId, baseSize); auto it cache_.find(key); if (it ! cache_.end()) { return it-second; } auto type std::make_sharedFireParticleType(defaultTexturePath, meshId, baseSize); cache_.emplace(std::move(key), type); return type; } size_t typeCount() const { return cache_.size(); } private: std::unordered_mapstd::pairint, float, std::shared_ptrconst ParticleType cache_; };实际项目里我会把工厂声明成单例或者注入依赖避免全局静态对象在多线程下的初始化顺序问题。单例的线程安全用std::once_flag包一层就够了。4. 实操过程中的关键细节与避坑指南4.1 生命周期管理千万别用裸指针做共享我在重构的早期版本用裸指针存享元对象的地址结果代码跑起来没几天就偶尔崩溃。反复排查后发现问题出在某些粒子还在存活状态时外部逻辑对ParticleType做了清理把缓存表清空了紧接着这些粒子再去调用type_-draw()就直接访问了野指针。所以我的结论是所有从工厂拿出来的享元对象一律用shared_ptr 承载。工厂本身持有唯一所有权但那是创建源头客户端也各自持有引用保证最后一个引用离开时对象才释放。这种生命周期由引用计数管理的方式在C里最不容易翻车。如果你担心shared_ptr的引用计数开销先量一下再决定。对粒子系统来说每帧要发生几千次共享指针的拷贝会有不小的引用计数增减开销。这时你可以换思路由工厂持有unique_ptr客户端拿原始指针同时保证客户端的生命周期一定比工厂短。但这就把安全的责任压到调用方头上了。生产环境里我建议先跑profile确认shared_ptr是瓶颈之后再考虑裸指针。4.2 工厂的线程安全第一个上线就踩的坑多线程生成粒子是刚需第一个版本上线当晚下了一场名副其实的粒子雨然后崩溃了。日志显示unordered_map的并发写导致迭代器失效。解决方案不复杂要么在get()方法里加锁要么用concurrent hashmap实现工厂缓存。我在方案权衡上选择了加锁方式因为get()内部就是查表加创建新对象临界区极短锁竞争开销可以接受。高频粒子生成的热点反而在客户端那边的vector上不在工厂里。class ThreadSafeParticleFactory { public: std::shared_ptrconst ParticleType get(int meshId, float baseSize) { std::lock_guardstd::mutex lock(mutex_); auto key std::make_pair(meshId, baseSize); auto it cache_.find(key); if (it ! cache_.end()) { return it-second; } auto type std::make_sharedFireParticleType(defaultTexturePath, meshId, baseSize); cache_.emplace(std::move(key), type); return type; } private: mutable std::mutex mutex_; std::unordered_mapstd::pairint, float, std::shared_ptrconst ParticleType cache_; };另外有一个细节即使工厂线程安全从工厂拿出来的共享对象本身也必须是const的。如果客户端拿到享元后还能修改内部状态那多线程的安全性就彻底归零了。所以我在接口上直接锁死了修改入口所有成员都是const只提供getter。4.3 什么时候不应该用享元模式享元模式不是万金油。三个判断条件不满足时别硬套。第一如果外部状态远比内部状态多也就是说每个对象的个体数据占了极大比重比如一个粒子有几十个独立字段而共享的只有一个小纹理ID那分离带来的增益几乎可以忽略不计还平白增加一层工厂查找和间接引用的复杂度。第二如果对象数量很少比如一个游戏里只有十几个敌人每个敌人也就几个属性你没必要去搞享元缓存直接new完拉倒。复杂度的增加是为了解决大规模问题小规模场景里属于过度设计。第三如果产品的业务需求频繁变化导致内部状态和外部状态的边界经常重新划分。每改一次边界就得动工厂键的构造、枚举类型的增减、缓存表的维护维护成本会明显高于收益。这种情况下先把需求稳定下来再谈优化模式。4.4 性能实测享元模式到底省了多少钱我最终对重构前后的性能做了对比测试。环境是Visual Studio 2022Windows 11Release模式处理器是i7-12700内存32GB。测试脚本让系统生成30000个粒子并跑300帧。重构前30000个粒子的内存占用峰值是912MB平均帧耗时16.8ms帧率约59fps粒子创建总耗时2.1秒。重构后同样的粒子数量内存占用降到66MB平均帧耗时6.3ms帧率约158fps创建总耗时0.4秒。内存节省了约92.7%帧耗时降低了62.5%。这个差距比我想象的还夸张因为优化的头号功臣不完全是内存本身而是内存减少后带来的缓存友好性和分配次数的大幅下降。4.5 调试经验如何验证享元真的被共享了有些时候代码跑起来内存也确实降了但你不确定到底是不是享元生效还是哪里误打误撞省了内存。我常用的办法是在工厂里加一个统计计数器记录缓存表的命中数cache hit和未命中数cache miss。struct FactoryStats { long long hitCount 0; long long missCount 0; size_t typeCount 0; };然后在get()方法里命中就hitCount未命中就missCount。压测之后如果hitCount远大于missCount说明复用非常充分如果missCount巨大说明你创建的享元类型种类过多几乎每个请求都是新类型这时候要考虑是不是内部状态的分割粒度有问题。还有一个更直观的验证方式打印工厂缓存表的大小。如果只有4种粒子里却有30000个粒子实例那享元的共享效率就是30000比4一目了然。5. 扩展思路从粒子到连接池与管理内核5.1 数据库连接池里的享元影子如果你理解透了享元模式再回头看数据库连接池你会发现它的设计本质也是享元思想的变体。数据库连接是昂贵资源连接池把已经创建好的连接缓存起来多个线程共享复用避免每次请求都重新创建、销毁连接。区别在于连接本身不是不可变对象所以连接池不能用直接共享同一个引用的方式必须通过获取-释放-再获取的循环来实现复用。但底层思路完全同源把重量级的、可复用的部分抽出来共享把每次请求特有的部分SQL语句、参数绑定作为外部状态传进去。5.2 与对象池模式的搭配使用享元模式是共享相同的对象对象池模式是复用已销毁的对象两者并不冲突反而经常搭配使用。在我的粒子系统重构里粒子个体对象Particle生命周期极短、创建销毁频繁我用了对象池来管理粒子类型对象ParticleType生命周期长、需要全局共享我用了享元模式来管理。两种模式各管一段整个系统的内存表现才会这么优秀。搭配使用时要注意顺序先享元后对象池。享元负责压缩同类型对象的重复状态对象池负责减少个体对象的创建销毁开销。如果只做对象池不做享元你复用一万个粒子对象但每个对象里还是带着自己那份纹理数据内存依然肥如果只做享元不做对象池创建销毁开销还在帧率依然会因为频繁new而抖动。5.3 在C20/23环境下的新写法如果你用的是C20或C23有一些新特性可以让享元实现更简洁。比如键类型可以用带默认太空泛比较的结构体直接作为unordered_map的键不用手写hash和equal。我在C20版本里就不用再手写ParticleTypeHash了直接用std::hash支持的类型组合键来构造// C20 可以用 std::tuple 作为 key标准库已经提供 hash 和 equal using ParticleTypeKey std::tuplestd::string, int, float; class Factory { std::unordered_mapParticleTypeKey, std::shared_ptrconst ParticleType cache_; public: std::shared_ptrconst ParticleType get(const std::string tex, int mesh, float size) { return cache_.try_emplace(ParticleTypeKey{tex, mesh, size}, std::make_sharedFireParticleType(tex, mesh, size)) .first-second; } };另外C17以后std::shared_ptr在栈上创建的成本有所下降移动语义也让内部状态的拷贝少了很多实测下来确实比老代码更省。5.4 后续还能怎么扩展这个系统如果游戏系统继续膨胀粒子系统的享元还有一层扩展空间把粒子的渲染行为也外部化。同一个ParticleType可以配置不同的着色器、混合模式、动画曲线这些配置再抽一层渲染预设结构。这时候享元工厂从管理粒子类型升级为管理渲染预设集每个粒子持有类型预设两个享元引用。这种二次享元在我做过的商业引擎里是很有价值的架构因为它能把资源共享的粒度从类型细化到渲染行为片段美术换配色、换渐变的时候根本不用新开类型对象改预设就行了。再往深走还能把数据驱动和享元结合起来粒子类型的定义全部由配置表JSON或二进制数据表驱动启动时工厂批量加载配置生成享元对象策划改数值、加类型都不用改代码只要动配置表。这也让享元的内部状态天然地适配了数据与逻辑分离的架构。我个人在实际项目里最深刻的体会是享元模式不是一种锦上添花的优化技巧它属于那种不到临界点你根本意识不到有问题的钱漏。粒子系统的重构花了我一个下午加一个晚上换来的是持续稳定的高帧率和远远宽松的内存余量。做C的人迟早要面对大规模并发对象的管理早点把内部状态和外部状态分离这个思路内化成下意识后面写什么系统都会顺畅很多。最后再分享一个小技巧所有涉及共享缓存的系统上线前务必在工厂里留一套统计接口至少能输出缓存条目数、命中率、创建总数这三个指标。没有这些数字撑着你真不知道享元到底帮你扛了多少内存性能优化是黑盒猜谜最折磨人了。