1. 内存告警背后的元凶上千种弹道特效的重复建模先说个我遇到过的真实场景。某客户端的战斗模块里有一批弹道特效每个子弹发射后都会在场景里生成一条轨迹轨迹上挂着一串光点数据。最初功能跑得好好的但等特效种类从十几个涨到上百个同屏子弹数量一多内存曲线就开始不对劲了。用 profiler 抓了一圈发现光是特效实例对象就占掉了将近三分之一的堆内存而这里面绝大多数数据——纹理路径、网格顶点、着色器参数、绑定的动画帧序列——在所有同类子弹之间是完全一样的。问题出在我们当时的设计上每个子弹对象在初始化时都会自己加载一套完整的特效配置包括材质资源、顶点缓存、动画采样同一种子弹生成一千发这一千份重复数据就实打实存了一千份。这个场景就是享元模式Flyweight Pattern的标准适用场景系统里存在大量细粒度的相似对象它们的大部分数据是相同的只有少数数据随着使用场景变化。享元模式的核心思路用一句话概括就是把对象中可共享的不变数据抽出来做成共享资源把随场景变化的数据放到外部由调用方临时传入。对应到上面那个弹道特效问题解法就是把状态拆成两部分内部状态Intrinsic State存储在 Flyweight 对象内部可以共享比如纹理、网格、特效类型ID。外部状态Extrinsic State不存储在 Flyweight 里由客户端在调用时传入比如子弹当前坐标、飞行方向、透明度随时间的衰减值。这样内存里的共享资源只有特效种类那么几份每个子弹只保留自己那几十个字节的动态数据。下面这篇实战记录就是围绕这个思路讲清楚 C 里怎么设计、怎么写、怎么避开那些光看《设计模式》书根本发现不了的坑。2. 先算状态账什么东西能共享什么东西必须外部传很多初学者上手享元模式第一个反应就是那我直接把成员变量都弄成 static 不就行了。这是最常见的误区。static 确实是共享但它把状态粒度锁死在了类级别一旦同一类对象需要同时存在多种不同配置比如同一种子弹有普通版和强化版static 方案直接崩盘。正确的做法是先做一次状态审计把每个对象的成员变量列出来逐一判定归属。判定标准我习惯用三个问题来推这个数据在对象整个生命周期里会不会变所有同类对象之间这个数据是否相同如果把它抽出去调用方每次传入的成本是否可接受如果问题一答会变直接归外部状态没什么好纠结的。如果问题二答相同那它就有共享潜力。如果共享后每次调用要多传一个参数但传参成本远低于复制一份数据的成本那就值得抽。拿我之前重构过的弹道特效模块举例。当时每个子弹对象里大概有十几个成员变量审计结果如下成员变量生命周期是否变化同类对象是否相同归属特效类型ID否是内部状态材质资源引用否是内部状态网格数据否是内部状态动画帧序列否是内部状态当前坐标是否外部状态飞行速度向量是否外部状态透明度衰减曲线进度是否外部状态绑定的逻辑AI组件指针是否外部状态这里有个很容易被忽略的细节所谓同类对象之间相同指的是逻辑语义相同不一定要求字面量完全相等。比如两个材质资源对象如果只是变量名不同但实际指向同一个资源 ID那它们在语义上就是相同的可以通过 ID 统一到同一个共享实例上。做完这一步你对享元模式的认知基本就成型了享元模式本质上不是在优化类的定义而是在管理状态的存储位置和复用粒度。后面所有代码和设计都是围绕这张状态归属表展开的。3. C 实战从零搭建一个线程安全的粒子享元工厂理论讲得再多不如直接看代码。我会用一个简化但完整的粒子系统 Demo 来演示整套实现。粒子系统是享元模式的教科书级场景——同屏几千个粒子每个粒子的纹理、形状、混合模式都是重复的只有位置、速度、生命周期是独立的。3.1 定义 Flyweight 基类与具体享元类第一步是先定义抽象享元类Flyweight。这个基类必须暴露一个接收外部状态的接口让调用方把变化数据传进来。在 C 里接口通常长这样// Flyweight.h #pragma once #include memory #include string // 外部状态粒子的动态属性 struct ParticleExtrinsicState { float x 0.f, y 0.f; // 当前位置 float velocityX 0.f; // 速度 float velocityY 0.f; float life 1.f; // 剩余生命 float alpha 1.f; // 透明度 }; // 抽象享元类 class ParticleFlyweight { public: virtual ~ParticleFlyweight() default; // 唯一需要外部传入参数的方法 virtual void render(const ParticleExtrinsicState state) const 0; // 供工厂和调试使用的标识 virtual const std::string typeId() const 0; };注意render方法接收的是外部状态的引用不是值拷贝。这是因为粒子每帧都要更新状态值拷贝会带来无谓的构造析构开销。但这也意味着调用方必须保证state在render执行期间是存活的——这个约束在后面的生命周期管理里要重点处理。第二步是定义具体享元类ConcreteFlyweight。以火焰粒子为例// FireParticle.h #pragma once #include ParticleFlyweight.h #include string class FireParticle : public ParticleFlyweight { public: explicit FireParticle(std::string texturePath) : m_texturePath(std::move(texturePath)) { // 构造函数里只装载内部状态这里模拟加载纹理资源 m_textureHandle loadTexture(m_texturePath); m_meshVertices generateMesh(32, 32); // 预生成网格顶点 } void render(const ParticleExtrinsicState state) const override { // 内部状态 外部状态 完整的渲染参数 drawTexturedQuad(m_textureHandle, m_meshVertices, state.x, state.y, state.velocityX, state.velocityY, state.alpha); } const std::string typeId() const override { return m_typeId; } private: std::string m_typeId FireParticle; std::string m_texturePath; TextureHandle m_textureHandle 0; std::vectorVertex m_meshVertices; };在我的实现里火焰粒子的纹理路径、纹理句柄、网格数据全都属于内部状态初始化一次之后不再变化。想象一下如果场景里有三千个火焰粒子传统写法会创建三千份纹理句柄和网格顶点用享元模式后无论多少个粒子这份数据只有一份。3.2 享元工厂唯一获取共享实例的入口有了具体享元类接下来要设计工厂FlyweightFactory。工厂的作用是维护一个共享池保证相同内部状态的粒子只创建一次。这里有个关键设计决策用什么作为共享池的查找 key。我用的是typeId 关键配置参数的组合键。因为同一种粒子可能有多种纹理变体比如火焰有大火苗和小火苗两种单靠类型名不足以区分// ParticleFlyweightFactory.h #pragma once #include unordered_map #include mutex #include memory #include string #include ParticleFlyweight.h #include FireParticle.h class ParticleFlyweightFactory { public: static ParticleFlyweightFactory instance() { static ParticleFlyweightFactory s_factory; return s_factory; } std::shared_ptrconst ParticleFlyweight getFireParticle(const std::string texturePath) { std::string key FireParticle: texturePath; // 先用共享池查一遍 { std::lock_guardstd::mutex lock(m_mutex); auto it m_pool.find(key); if (it ! m_pool.end()) { return it-second; } } // 没有命中创建新实例并放入共享池 auto newParticle std::make_sharedFireParticle(texturePath); { std::lock_guardstd::mutex lock(m_mutex); // 双重检查锁定防止两个线程同时创建同一个 key 的实例 auto it m_pool.find(key); if (it ! m_pool.end()) { return it-second; } m_pool[key] newParticle; return newParticle; } } size_t poolSize() const { std::lock_guardstd::mutex lock(m_mutex); return m_pool.size(); } private: ParticleFlyweightFactory() default; mutable std::mutex m_mutex; std::unordered_mapstd::string, std::shared_ptrconst ParticleFlyweight m_pool; };这里有几个用 C 实现享元工厂时特别要注意的点我一个个说。第一点是返回类型用shared_ptrconst而不是裸指针或普通指针。享元对象一旦创建它的内部状态必须不可变。用const来约束调用方能在编译期就防止有人不小心改了共享数据。一旦都拿到同一个const对象引用任何修改意图都会被编译器拦下来这是对共享资源最基本、也是成本最低的保护。第二点是线程安全。游戏逻辑线程和渲染线程经常会同时访问粒子系统。如果工厂不加锁两个线程同时getFireParticle同一个 key就是典型的 data race 场景。我在实现里用了std::mutex加双重检查锁定先用普通查找降低锁竞争没有命中才持有锁创建对象。这里必须做双重检查而不是创建前查一次就完事否则在锁竞争激烈时可能创建出两份相同 key 的实例。第三点是 key 的设计。很多第一次写享元模式的人会把 key 直接设计成对象哈希或直接拿类型名。如果内部状态很复杂——比如网格数据本身就是几百 KB 的字节流——直接拿完整数据当 key 会导致 unordered_map 的哈希计算成本高到得不偿失。成本评估要算总账key 的生成哈希开销 vs 避免重复创建的存储开销哪种更划算。在我的场景里组合 key 是 FireParticle 纹理路径纹理路径是短字符串哈希开销可以忽略。3.3 调用端的使用方式外部状态由客户端管理设计完工厂下面看调用端怎么用。在实际的粒子系统里通常由一个ParticleSystem统一管理所有粒子的动态状态。每个粒子在逻辑上仍然是一个对象但这个对象不再是一个传统的 C 类实例而是共享享元 独有外部状态的组合。// ParticleSystem.h #pragma once #include memory #include vector #include ParticleFlyweightFactory.h class ParticleSystem { public: void spawnFireParticle(float x, float y, const std::string texturePath) { // 关键工厂只返回共享的享元对象 auto flyweight ParticleFlyweightFactory::instance() .getFireParticle(texturePath); // 外部状态是每个粒子独有的 ParticleExtrinsicState state; state.x x; state.y y; state.velocityX randomFloat(-1.f, 1.f); state.velocityY randomFloat(0.f, 1.f); m_particles.emplace_back(std::move(flyweight), std::move(state)); } void update(float dt) { for (auto particle : m_particles) { auto [flyweight, state] particle; // 更新外部状态 state.x state.velocityX * dt; state.y state.velocityY * dt; state.life - dt; // 渲染时把外部状态传给享元对象 flyweight-render(state); } } private: struct ParticleInstance { std::shared_ptrconst ParticleFlyweight flyweight; ParticleExtrinsicState state; }; std::vectorParticleInstance m_particles; };这个设计有个很重要的思维转换在享元模式里对象这个概念被解耦了。传统面向对象思维认为一个对象必须在一个类实例里完整描述但享元模式下一个逻辑粒子的完整状态是由shared_ptrconst ParticleFlyweight共享部分和ParticleExtrinsicState独有部分拼起来的。这两部分共同构成一个逻辑对象但物理上存在不同的存储区域。这种解耦对代码组织的冲击是真实的。初始重构时团队成员普遍不适应为什么粒子类里没有坐标成员为什么渲染要显式传坐标但适应之后会发现整个系统的扩展性反而更好了。比如新增一种爆炸粒子只需要新写一个ExplosionParticle类然后在工厂里加一个getExplosionParticle方法粒子系统主逻辑完全不用改。4. 内存账本重构前后到底省了多少前面讲了设计和实现现在上实测数据。为了验证享元模式在这套粒子系统里的收益我做了一个对照实验分别用传统每个粒子一个完整对象的写法和享元模式的写法生成一万个粒子测量内存占用和初始化耗时。传统写法下每个粒子对象都包含TextureHandle8字节、网格顶点16KB、动画帧序列约4KB。一万个粒子仅网格和动画数据就占掉大约 200MB还不算每个对象单独的纹理加载耗时。享元写法的测量结果如下项目传统写法享元写法粒子总数10,00010,000内部状态对象数10,0005内部状态内存网格动画句柄200 MB100 KB外部状态实例数010,000外部状态内存坐标速度生命0320 KB总内存200 MB约 0.42 MB初始化耗时模拟资源加载约 32 秒约 80 毫秒实测数据比我预想的还要夸张。初始化耗时的差距主要来自资源加载——传统写法每个粒子都要重新加载纹理和生成网格这一万次 I/O 和计算跑下来就是三十多秒享元写法只有 5 种不同的纹理变体加载 5 次就完事了。这里面有一个值得说的测量技巧C 里测量对象真正内存占用不能只看sizeof因为sizeof只反映对象本身不反映对象内部指针指向的堆数据。正确做法是用操作系统的内存统计接口比如进程的 RSS在初始化前后各打一次点差值就是真实的内存增量。5. 实战中容易踩的坑生命周期、悬垂引用和调试陷阱代码能跑通demo 数据也很好看但真正把享元模式稳定用起来还要过几道坎。我在这套粒子系统的后续维护中前后踩了四个比较典型的坑每个都值得单拎出来说。5.1 共享对象的生命周期如何收尾第一个坑是生命周期管理。享元对象一旦创建就长期驻留在工厂的unordered_map里如果游戏切换场景后所有粒子都销毁了但共享池还在那这部分内存就一直占着。解决方案可以给工厂加一个释放空闲共享对象的方法根据引用计数判断是否还有外部持有引用void ParticleFlyweightFactory::releaseUnused() { std::lock_guardstd::mutex lock(m_mutex); for (auto it m_pool.begin(); it ! m_pool.end(); ) { // 引用计数为1说明只有共享池持有 if (it-second.use_count() 1) { it m_pool.erase(it); } else { it; } } }调用时机可以放在场景卸载后、加载新场景前。这个模式本质上是在共享池和应用生命周期之间做了一个对齐避免共享资源无限膨胀。5.2 不要让外部状态持有者悬垂第二个坑也是 C 专属的坑是共享对象的引用计数值与外部状态生命周期可能不匹配。我之前在处理粒子死亡事件时对某个粒子的外部状态持有引用结果粒子被提前回收状态数据的内存被释放下一次render时读取到的就是悬垂引用。规避办法是在粒子系统中用一个衍生数据结构管理所有存活粒子的外部状态粒子销毁时先从这个数据结构里摘除再让render统一轮询有效集合。不要在业务代码里到处散落ParticleExtrinsicState的裸引用。std::vectorParticleExtrinsicState m_externalStates; // 连续内存池 std::vectorbool m_aliveFlags; // 存活标记用连续内存池而不用链表或散列是为了保证render高频调用时外部状态访问是缓存友好的。这个优化在粒子数量大、每帧都全量遍历时收益非常明显。5.3 调试时如何证明共享真的生效了第三个坑比较隐蔽——享元模式调试困难。代码逻辑写错了往往不是崩溃而是某个粒子长得不对。因为共享对象被多个逻辑实体共用任何对内部状态的破坏性修改都会导致所有共享它的粒子集体出错。有一个很实用的调试技巧给每个共享实例的创建位置打一个唯一的地址日志。在工厂创建新实例时把实例地址、类型、key 记录到日志。运行时如果发现某个粒子渲染异常去日志里查这个粒子的享元地址然后检查同一地址被哪些粒子共享了。如果那些粒子全都异常基本可以断定是共享数据被篡改如果只有个别异常那问题出在外部状态上。我在代码里加过一个共享一致性校验的配置开关在开发版本打开后每次render前会校验内部状态的关键哈希值是否一致。性能当然有损耗但调试期换取的价值极高。5.4 外部状态字段的拷贝开销最后一个坑来自外部状态本身。ParticleExtrinsicState如果设计得臃肿比如塞了一整个std::vector进去那每次调用render传引用没问题但在emplace_back和粒子复制时拷贝开销会重新冒出来。我的建议是外部状态只保留 POD 类型的标量字段浮点数、ID、小结构体凡是超过 64 字节的变动数据用shared_ptr间接引用避免深拷贝。6. 享元模式的边界感它和对象池、原型模式的区别最后聊聊我在项目复盘时的思考。享元模式在 C 项目中经常被误用或混淆尤其是和对象池Object Pool、原型模式Prototype放在一起时很多人分不清边界。对象池解决的是创建和销毁成本问题它复用的是已经分配好的内存块但每个对象仍然持有自己独立的数据。粒子对象池创建出来的 1000 个对象每个都有自己的一份纹理句柄。享元模式解决的是存储冗余问题它复用的是数据本身。如果需求是粒子频繁创建销毁导致性能卡顿应该用对象池如果需求是对象数量大但数据大量相同导致内存暴涨应该用享元。原型模式解决的是复制一个配置复杂的对象的问题。它通过克隆已有对象来避免从零构造。原型模式和享元模式有相似之处都是避免重复创建但原型的产物是独立的对象修改克隆体不会影响原对象享元的产物是共享的同一份数据任何修改都会影响所有使用者。这三者的关系可以用一个生活类比来收束对象池是家里常备一次性餐具随用随洗循环使用原型模式是照着菜谱再做一份一摸一样的菜享元模式是所有人共用同一个菜谱只在自己碗里调整夹菜量。三个模式解决的是三个完全不同维度的问题选择时先分清资源瓶颈到底在哪里。回到当初那个弹道特效项目。重构带来的直接收益是特效模块的内存占用从平台峰值里显著下降同屏子弹数量上限翻了一倍。但我觉得更重要的收益是团队对状态归属这件事建立了统一认知后面再做渲染相关模块时大家会先问一句这个数据是所有对象都一样的还是每个对象各一份的——就这一个习惯就足以避免很多性能问题的提前发生。最后再分享一个我在用享元模式时养成的习惯无论内部状态结构多简单都给它加一个只读的调试接口输出当前共享实例的地址、创建时间、复用次数。这些数据在性能分析和问题定位时能省下大量排查时间。复现一个线上性能问题你翻内存快照找不到共享对象被谁引用时这个调试接口就是唯一的抓手。
1. 内存告警背后的元凶上千种弹道特效的重复建模先说个我遇到过的真实场景。某客户端的战斗模块里有一批弹道特效每个子弹发射后都会在场景里生成一条轨迹轨迹上挂着一串光点数据。最初功能跑得好好的但等特效种类从十几个涨到上百个同屏子弹数量一多内存曲线就开始不对劲了。用 profiler 抓了一圈发现光是特效实例对象就占掉了将近三分之一的堆内存而这里面绝大多数数据——纹理路径、网格顶点、着色器参数、绑定的动画帧序列——在所有同类子弹之间是完全一样的。问题出在我们当时的设计上每个子弹对象在初始化时都会自己加载一套完整的特效配置包括材质资源、顶点缓存、动画采样同一种子弹生成一千发这一千份重复数据就实打实存了一千份。这个场景就是享元模式Flyweight Pattern的标准适用场景系统里存在大量细粒度的相似对象它们的大部分数据是相同的只有少数数据随着使用场景变化。享元模式的核心思路用一句话概括就是把对象中可共享的不变数据抽出来做成共享资源把随场景变化的数据放到外部由调用方临时传入。对应到上面那个弹道特效问题解法就是把状态拆成两部分内部状态Intrinsic State存储在 Flyweight 对象内部可以共享比如纹理、网格、特效类型ID。外部状态Extrinsic State不存储在 Flyweight 里由客户端在调用时传入比如子弹当前坐标、飞行方向、透明度随时间的衰减值。这样内存里的共享资源只有特效种类那么几份每个子弹只保留自己那几十个字节的动态数据。下面这篇实战记录就是围绕这个思路讲清楚 C 里怎么设计、怎么写、怎么避开那些光看《设计模式》书根本发现不了的坑。2. 先算状态账什么东西能共享什么东西必须外部传很多初学者上手享元模式第一个反应就是那我直接把成员变量都弄成 static 不就行了。这是最常见的误区。static 确实是共享但它把状态粒度锁死在了类级别一旦同一类对象需要同时存在多种不同配置比如同一种子弹有普通版和强化版static 方案直接崩盘。正确的做法是先做一次状态审计把每个对象的成员变量列出来逐一判定归属。判定标准我习惯用三个问题来推这个数据在对象整个生命周期里会不会变所有同类对象之间这个数据是否相同如果把它抽出去调用方每次传入的成本是否可接受如果问题一答会变直接归外部状态没什么好纠结的。如果问题二答相同那它就有共享潜力。如果共享后每次调用要多传一个参数但传参成本远低于复制一份数据的成本那就值得抽。拿我之前重构过的弹道特效模块举例。当时每个子弹对象里大概有十几个成员变量审计结果如下成员变量生命周期是否变化同类对象是否相同归属特效类型ID否是内部状态材质资源引用否是内部状态网格数据否是内部状态动画帧序列否是内部状态当前坐标是否外部状态飞行速度向量是否外部状态透明度衰减曲线进度是否外部状态绑定的逻辑AI组件指针是否外部状态这里有个很容易被忽略的细节所谓同类对象之间相同指的是逻辑语义相同不一定要求字面量完全相等。比如两个材质资源对象如果只是变量名不同但实际指向同一个资源 ID那它们在语义上就是相同的可以通过 ID 统一到同一个共享实例上。做完这一步你对享元模式的认知基本就成型了享元模式本质上不是在优化类的定义而是在管理状态的存储位置和复用粒度。后面所有代码和设计都是围绕这张状态归属表展开的。3. C 实战从零搭建一个线程安全的粒子享元工厂理论讲得再多不如直接看代码。我会用一个简化但完整的粒子系统 Demo 来演示整套实现。粒子系统是享元模式的教科书级场景——同屏几千个粒子每个粒子的纹理、形状、混合模式都是重复的只有位置、速度、生命周期是独立的。3.1 定义 Flyweight 基类与具体享元类第一步是先定义抽象享元类Flyweight。这个基类必须暴露一个接收外部状态的接口让调用方把变化数据传进来。在 C 里接口通常长这样// Flyweight.h #pragma once #include memory #include string // 外部状态粒子的动态属性 struct ParticleExtrinsicState { float x 0.f, y 0.f; // 当前位置 float velocityX 0.f; // 速度 float velocityY 0.f; float life 1.f; // 剩余生命 float alpha 1.f; // 透明度 }; // 抽象享元类 class ParticleFlyweight { public: virtual ~ParticleFlyweight() default; // 唯一需要外部传入参数的方法 virtual void render(const ParticleExtrinsicState state) const 0; // 供工厂和调试使用的标识 virtual const std::string typeId() const 0; };注意render方法接收的是外部状态的引用不是值拷贝。这是因为粒子每帧都要更新状态值拷贝会带来无谓的构造析构开销。但这也意味着调用方必须保证state在render执行期间是存活的——这个约束在后面的生命周期管理里要重点处理。第二步是定义具体享元类ConcreteFlyweight。以火焰粒子为例// FireParticle.h #pragma once #include ParticleFlyweight.h #include string class FireParticle : public ParticleFlyweight { public: explicit FireParticle(std::string texturePath) : m_texturePath(std::move(texturePath)) { // 构造函数里只装载内部状态这里模拟加载纹理资源 m_textureHandle loadTexture(m_texturePath); m_meshVertices generateMesh(32, 32); // 预生成网格顶点 } void render(const ParticleExtrinsicState state) const override { // 内部状态 外部状态 完整的渲染参数 drawTexturedQuad(m_textureHandle, m_meshVertices, state.x, state.y, state.velocityX, state.velocityY, state.alpha); } const std::string typeId() const override { return m_typeId; } private: std::string m_typeId FireParticle; std::string m_texturePath; TextureHandle m_textureHandle 0; std::vectorVertex m_meshVertices; };在我的实现里火焰粒子的纹理路径、纹理句柄、网格数据全都属于内部状态初始化一次之后不再变化。想象一下如果场景里有三千个火焰粒子传统写法会创建三千份纹理句柄和网格顶点用享元模式后无论多少个粒子这份数据只有一份。3.2 享元工厂唯一获取共享实例的入口有了具体享元类接下来要设计工厂FlyweightFactory。工厂的作用是维护一个共享池保证相同内部状态的粒子只创建一次。这里有个关键设计决策用什么作为共享池的查找 key。我用的是typeId 关键配置参数的组合键。因为同一种粒子可能有多种纹理变体比如火焰有大火苗和小火苗两种单靠类型名不足以区分// ParticleFlyweightFactory.h #pragma once #include unordered_map #include mutex #include memory #include string #include ParticleFlyweight.h #include FireParticle.h class ParticleFlyweightFactory { public: static ParticleFlyweightFactory instance() { static ParticleFlyweightFactory s_factory; return s_factory; } std::shared_ptrconst ParticleFlyweight getFireParticle(const std::string texturePath) { std::string key FireParticle: texturePath; // 先用共享池查一遍 { std::lock_guardstd::mutex lock(m_mutex); auto it m_pool.find(key); if (it ! m_pool.end()) { return it-second; } } // 没有命中创建新实例并放入共享池 auto newParticle std::make_sharedFireParticle(texturePath); { std::lock_guardstd::mutex lock(m_mutex); // 双重检查锁定防止两个线程同时创建同一个 key 的实例 auto it m_pool.find(key); if (it ! m_pool.end()) { return it-second; } m_pool[key] newParticle; return newParticle; } } size_t poolSize() const { std::lock_guardstd::mutex lock(m_mutex); return m_pool.size(); } private: ParticleFlyweightFactory() default; mutable std::mutex m_mutex; std::unordered_mapstd::string, std::shared_ptrconst ParticleFlyweight m_pool; };这里有几个用 C 实现享元工厂时特别要注意的点我一个个说。第一点是返回类型用shared_ptrconst而不是裸指针或普通指针。享元对象一旦创建它的内部状态必须不可变。用const来约束调用方能在编译期就防止有人不小心改了共享数据。一旦都拿到同一个const对象引用任何修改意图都会被编译器拦下来这是对共享资源最基本、也是成本最低的保护。第二点是线程安全。游戏逻辑线程和渲染线程经常会同时访问粒子系统。如果工厂不加锁两个线程同时getFireParticle同一个 key就是典型的 data race 场景。我在实现里用了std::mutex加双重检查锁定先用普通查找降低锁竞争没有命中才持有锁创建对象。这里必须做双重检查而不是创建前查一次就完事否则在锁竞争激烈时可能创建出两份相同 key 的实例。第三点是 key 的设计。很多第一次写享元模式的人会把 key 直接设计成对象哈希或直接拿类型名。如果内部状态很复杂——比如网格数据本身就是几百 KB 的字节流——直接拿完整数据当 key 会导致 unordered_map 的哈希计算成本高到得不偿失。成本评估要算总账key 的生成哈希开销 vs 避免重复创建的存储开销哪种更划算。在我的场景里组合 key 是 FireParticle 纹理路径纹理路径是短字符串哈希开销可以忽略。3.3 调用端的使用方式外部状态由客户端管理设计完工厂下面看调用端怎么用。在实际的粒子系统里通常由一个ParticleSystem统一管理所有粒子的动态状态。每个粒子在逻辑上仍然是一个对象但这个对象不再是一个传统的 C 类实例而是共享享元 独有外部状态的组合。// ParticleSystem.h #pragma once #include memory #include vector #include ParticleFlyweightFactory.h class ParticleSystem { public: void spawnFireParticle(float x, float y, const std::string texturePath) { // 关键工厂只返回共享的享元对象 auto flyweight ParticleFlyweightFactory::instance() .getFireParticle(texturePath); // 外部状态是每个粒子独有的 ParticleExtrinsicState state; state.x x; state.y y; state.velocityX randomFloat(-1.f, 1.f); state.velocityY randomFloat(0.f, 1.f); m_particles.emplace_back(std::move(flyweight), std::move(state)); } void update(float dt) { for (auto particle : m_particles) { auto [flyweight, state] particle; // 更新外部状态 state.x state.velocityX * dt; state.y state.velocityY * dt; state.life - dt; // 渲染时把外部状态传给享元对象 flyweight-render(state); } } private: struct ParticleInstance { std::shared_ptrconst ParticleFlyweight flyweight; ParticleExtrinsicState state; }; std::vectorParticleInstance m_particles; };这个设计有个很重要的思维转换在享元模式里对象这个概念被解耦了。传统面向对象思维认为一个对象必须在一个类实例里完整描述但享元模式下一个逻辑粒子的完整状态是由shared_ptrconst ParticleFlyweight共享部分和ParticleExtrinsicState独有部分拼起来的。这两部分共同构成一个逻辑对象但物理上存在不同的存储区域。这种解耦对代码组织的冲击是真实的。初始重构时团队成员普遍不适应为什么粒子类里没有坐标成员为什么渲染要显式传坐标但适应之后会发现整个系统的扩展性反而更好了。比如新增一种爆炸粒子只需要新写一个ExplosionParticle类然后在工厂里加一个getExplosionParticle方法粒子系统主逻辑完全不用改。4. 内存账本重构前后到底省了多少前面讲了设计和实现现在上实测数据。为了验证享元模式在这套粒子系统里的收益我做了一个对照实验分别用传统每个粒子一个完整对象的写法和享元模式的写法生成一万个粒子测量内存占用和初始化耗时。传统写法下每个粒子对象都包含TextureHandle8字节、网格顶点16KB、动画帧序列约4KB。一万个粒子仅网格和动画数据就占掉大约 200MB还不算每个对象单独的纹理加载耗时。享元写法的测量结果如下项目传统写法享元写法粒子总数10,00010,000内部状态对象数10,0005内部状态内存网格动画句柄200 MB100 KB外部状态实例数010,000外部状态内存坐标速度生命0320 KB总内存200 MB约 0.42 MB初始化耗时模拟资源加载约 32 秒约 80 毫秒实测数据比我预想的还要夸张。初始化耗时的差距主要来自资源加载——传统写法每个粒子都要重新加载纹理和生成网格这一万次 I/O 和计算跑下来就是三十多秒享元写法只有 5 种不同的纹理变体加载 5 次就完事了。这里面有一个值得说的测量技巧C 里测量对象真正内存占用不能只看sizeof因为sizeof只反映对象本身不反映对象内部指针指向的堆数据。正确做法是用操作系统的内存统计接口比如进程的 RSS在初始化前后各打一次点差值就是真实的内存增量。5. 实战中容易踩的坑生命周期、悬垂引用和调试陷阱代码能跑通demo 数据也很好看但真正把享元模式稳定用起来还要过几道坎。我在这套粒子系统的后续维护中前后踩了四个比较典型的坑每个都值得单拎出来说。5.1 共享对象的生命周期如何收尾第一个坑是生命周期管理。享元对象一旦创建就长期驻留在工厂的unordered_map里如果游戏切换场景后所有粒子都销毁了但共享池还在那这部分内存就一直占着。解决方案可以给工厂加一个释放空闲共享对象的方法根据引用计数判断是否还有外部持有引用void ParticleFlyweightFactory::releaseUnused() { std::lock_guardstd::mutex lock(m_mutex); for (auto it m_pool.begin(); it ! m_pool.end(); ) { // 引用计数为1说明只有共享池持有 if (it-second.use_count() 1) { it m_pool.erase(it); } else { it; } } }调用时机可以放在场景卸载后、加载新场景前。这个模式本质上是在共享池和应用生命周期之间做了一个对齐避免共享资源无限膨胀。5.2 不要让外部状态持有者悬垂第二个坑也是 C 专属的坑是共享对象的引用计数值与外部状态生命周期可能不匹配。我之前在处理粒子死亡事件时对某个粒子的外部状态持有引用结果粒子被提前回收状态数据的内存被释放下一次render时读取到的就是悬垂引用。规避办法是在粒子系统中用一个衍生数据结构管理所有存活粒子的外部状态粒子销毁时先从这个数据结构里摘除再让render统一轮询有效集合。不要在业务代码里到处散落ParticleExtrinsicState的裸引用。std::vectorParticleExtrinsicState m_externalStates; // 连续内存池 std::vectorbool m_aliveFlags; // 存活标记用连续内存池而不用链表或散列是为了保证render高频调用时外部状态访问是缓存友好的。这个优化在粒子数量大、每帧都全量遍历时收益非常明显。5.3 调试时如何证明共享真的生效了第三个坑比较隐蔽——享元模式调试困难。代码逻辑写错了往往不是崩溃而是某个粒子长得不对。因为共享对象被多个逻辑实体共用任何对内部状态的破坏性修改都会导致所有共享它的粒子集体出错。有一个很实用的调试技巧给每个共享实例的创建位置打一个唯一的地址日志。在工厂创建新实例时把实例地址、类型、key 记录到日志。运行时如果发现某个粒子渲染异常去日志里查这个粒子的享元地址然后检查同一地址被哪些粒子共享了。如果那些粒子全都异常基本可以断定是共享数据被篡改如果只有个别异常那问题出在外部状态上。我在代码里加过一个共享一致性校验的配置开关在开发版本打开后每次render前会校验内部状态的关键哈希值是否一致。性能当然有损耗但调试期换取的价值极高。5.4 外部状态字段的拷贝开销最后一个坑来自外部状态本身。ParticleExtrinsicState如果设计得臃肿比如塞了一整个std::vector进去那每次调用render传引用没问题但在emplace_back和粒子复制时拷贝开销会重新冒出来。我的建议是外部状态只保留 POD 类型的标量字段浮点数、ID、小结构体凡是超过 64 字节的变动数据用shared_ptr间接引用避免深拷贝。6. 享元模式的边界感它和对象池、原型模式的区别最后聊聊我在项目复盘时的思考。享元模式在 C 项目中经常被误用或混淆尤其是和对象池Object Pool、原型模式Prototype放在一起时很多人分不清边界。对象池解决的是创建和销毁成本问题它复用的是已经分配好的内存块但每个对象仍然持有自己独立的数据。粒子对象池创建出来的 1000 个对象每个都有自己的一份纹理句柄。享元模式解决的是存储冗余问题它复用的是数据本身。如果需求是粒子频繁创建销毁导致性能卡顿应该用对象池如果需求是对象数量大但数据大量相同导致内存暴涨应该用享元。原型模式解决的是复制一个配置复杂的对象的问题。它通过克隆已有对象来避免从零构造。原型模式和享元模式有相似之处都是避免重复创建但原型的产物是独立的对象修改克隆体不会影响原对象享元的产物是共享的同一份数据任何修改都会影响所有使用者。这三者的关系可以用一个生活类比来收束对象池是家里常备一次性餐具随用随洗循环使用原型模式是照着菜谱再做一份一摸一样的菜享元模式是所有人共用同一个菜谱只在自己碗里调整夹菜量。三个模式解决的是三个完全不同维度的问题选择时先分清资源瓶颈到底在哪里。回到当初那个弹道特效项目。重构带来的直接收益是特效模块的内存占用从平台峰值里显著下降同屏子弹数量上限翻了一倍。但我觉得更重要的收益是团队对状态归属这件事建立了统一认知后面再做渲染相关模块时大家会先问一句这个数据是所有对象都一样的还是每个对象各一份的——就这一个习惯就足以避免很多性能问题的提前发生。最后再分享一个我在用享元模式时养成的习惯无论内部状态结构多简单都给它加一个只读的调试接口输出当前共享实例的地址、创建时间、复用次数。这些数据在性能分析和问题定位时能省下大量排查时间。复现一个线上性能问题你翻内存快照找不到共享对象被谁引用时这个调试接口就是唯一的抓手。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
