1. 先说结论GC卡顿是症状对象数量失控和隐性引用才是病根1.1 一个让帧率曲线周期性跳崖的经典案例如果你在项目里遇到过这种场景玩家在大世界地图上跑得好好的突然一下帧率掉到个位数然后又恢复Debug工具里没有任何报错也没有资源流送日志那大概率不是美术资源或渲染问题而是GCGarbage Collection垃圾回收在背后运作。这类问题我在UE4时代就排查过很多轮到了UE5World Partition、异步加载、大量Actor常驻大世界后情况变得更严重也更隐蔽。我印象最深的一个案例如下。一款大世界玩法的项目测试时发现帧率曲线每隔大约60秒到90秒就会出现一次明显的尖峰单帧耗时从8ms直接跳到100ms以上。起初怀疑是贴图流送或导航网格重计算但所有和加载相关的日志都干干净净。后来把GC的统计打开真相才浮出水面——引擎每过一段时间做一次可达性分析恰好在这个时间点扫到了数量庞大的临时对象。这些对象本该在玩家离开某片区域时被释放但因为某个系统里的引用没断干净导致它们一直堆在内存里GC的标记阶段必须逐一遍历遍历越久卡顿就越明显。这个案例说明一个很核心的问题GC卡顿是症状不是病因。如果你直接去调GC参数或者手动触发GC大概率只会把问题往后推迟十几分钟然后原样复发。真正要查的是两件事——UObject的总量为什么失控以及哪些残留引用阻止了对象被回收。1.2 UE5的GC到底在做什么很多人用了好几年UE对GC的理解还停留在定期清理不用的对象这个层面这会导致排查时毫无头绪。我简单梳理一下UE5的GC流程理解了它后续定位就有方向。UE的GC不是引用计数而是标记-清除Mark-Sweep式可达性分析。引擎从一组根集合Root Set出发沿着UObject之间的强引用遍历整个对象图能遍历到的对象标记为存活遍历不到的对象则判定为不可达进入待销毁队列最后依次调用它们的BeginDestroy、FinishDestroy并释放内存。这个过程有三个关键特征决定了它为什么会在某些项目中疯狂卡顿标记阶段要遍历所有可达对象。如果场景里常驻了一万个Actor每个Actor挂着若干Component、贴图、动画资产引用那这就是一个非常庞大的图。GC每次标记都要把它们全部走一遍。遍历是近似逐帧的。UE5.0之后引入了增量GC的尝试可以把标记阶段拆到多帧去执行但默认情况下很多项目并没有真正打开或者打开了之后单帧峰值变成持续性的每帧小开销反而更难受。UObject不是普通C对象。它要进GC对象图、要带UClass属性信息、要被全局对象链表维护着。也可以说每创建一个UObject就是在给将来的GC标记阶段增加一份工作量同时反射系统还要为它付出额外的内存。为了便于理解可以把GC的标记阶段想象成一个小区物业要挨家挨户核实住户。小区里的房间UObject越多、走廊引用链越复杂一次大扫除需要的时间就越长。如果你把一堆本该拆掉的违建也一直留着每次扫楼都要多走一遍时间一长整个小区每扫一次楼都会卡住大门影响所有人进出。所以对GC优化的第一原则是先降低UObject的总量再谈GC本身。总量降下来了即使参数不动卡顿也会肉眼可见地缓解。2. 用数据说话快速确认卡顿来自GC的检查链路2.1 第一轮筛查stat gc stat memory五分钟看明白怀疑GC卡顿不要一上来就改代码先用引擎提供的统计命令确认方向。在Console窗口依次执行stat gc stat memorystat gc会显示最近一次以及平均的GC耗时、当前UObject数量、每帧执行GC的时间等信息。重点看几个字段Total Time单次GC的总耗时如果这个数字超过30ms甚至50ms就已经非常值得关注。Mark Time可达性标记耗时。如果它占大头说明对象图庞大或引用链复杂。Destroy Time销毁不可达对象耗时。如果它占大头说明每一轮有大量对象同时被销毁通常是批量产生了大量临时对象。stat memory可以看到内存总量和主要分类。注意对比正常状态和明显卡顿状态下的差异。为了制造可对比的数据我建议按以下脚本操作进入一个安静场景等1分钟记录stat gc和stat memory的基线数据。执行目标系统的打开-关闭操作若干次例如反复开关UI、进出战斗、反复过传送点。回到同一场景再等1分钟观察GC耗时是否有明显爬升趋势。如果GC耗时从20ms涨到60ms基本可以断定对象积累或引用残留的问题已经存在。这时候可以用memreport再生成一份完整的内存快照后续分析时作为参照。2.2 用UnrealInsights把GC过程切成帧看统计命令告诉你有问题但没法告诉你问题发生在哪一帧的哪个阶段。这一步建议交给UnrealInsights。用 -tracecpu 参数启动游戏或者在运行中用 trace.start 命令开始捕获然后复现卡顿操作。结束后在UnrealInsights的CPU时间线里找到GarbageCollection相关的Track观察每次GC的耗时分布尤其注意以下几点GC事件是否和帧率尖峰严格对应。GC的Mark阶段是否在逐次增长。GC前后是否有大量Actor的BeginDestroy事件。如果有你要去看看哪里在同一帧里销毁了几百个对象这是另一种常见的卡顿来源——即使它们能被正常回收集中销毁的瞬时开销也很大。UnrealInsights的时间线还能看到GC和异步加载线程的交互。有的项目里GC卡顿和流送Level的卸载互相干扰单看GC统计反而容易误判。有了时间线我经常发现卡顿并不全是GC本身而是GC和资源卸载撞在同一个主线程帧里属于串联延迟排查思路就又不一样了。2.3 obj list让对象数量暴露在阳光下这是我最常用的证据收集手段。在游戏运行中打开控制台执行obj list引擎会输出当前进程里所有UObject的统计信息按Class分组显示数量和占用内存。重点盯几个类型Actor、Pawn、Character、PlayerControllerWidget / UserWidgetTexture、MaterialInstance、StaticMeshSoundBase等音频资源复现一次操作前后各执行一次obj list对比各类型数量变化。如果你发现某个类别的对象数量操作一次增加若干关闭后完全不减少那恭喜这一条几乎就是铁证。比如你反复开关一个通用弹窗10次后UserWidget的数量比初始状态多了10个这就说明有10个Widget没有被GC回收。要么是有人在它们关闭后还保留着强引用要么是UI系统自身的栈结构没有弹干净。这里有一个经验很多人喜欢看总内存判断泄漏但内存这玩意儿被资源缓存、渲染缓冲、池化机制干扰太多。对象的数量清单比内存数字可靠得多。对象数不会骗人只要符合只增不减的规律就一定存在生命周期管理问题剩下的只是顺藤摸瓜。3. 对象泄漏的三大典型藏身之处与排查实录3.1 案例一UI面板反复开关后UserWidget数量只增不减某项目上线前的性能测试中发现一个很隐蔽的问题打开商店界面再关闭反复20次后游戏的整体帧率从60掉到了45而且再也不会恢复。用前面说的obj list对比UserWidget的数量从基线值一路增长每开一次商店就增加若干个。排查链路是这样的。我先怀疑关闭逻辑没走对检查了Widget的关闭按钮调用RemoveFromParent确实调了但这是Slate层的移除只是把它从视口上去掉并不代表UObject被销毁。真正决定它能否被GC回收的是还有没有其他UObject强引用指向它。后来追踪发现UI管理器用一个UPROPERTY数组保存了所有打开过的Widget的强引用本意是为了统一管理但数组只进不出每个关闭的Widget都被留在了数组里。数组持有了强引用GC就认为这些Widget仍然存活永远不可达。修复方式很直接在UI管理器的关闭栈里把目标Widget的强引用移除并且调用ReleaseSlateResources释放Slate侧的资源。改完后反复打开关闭20次对象数量回到基线。这里有一个值得记住的规律UI问题十有八九是对象栈或缓存列表只增不减造成的。写UI管理器时任何打开时Push、关闭时记得Pop的对称性都必须严格保证。3.2 案例二StreamableHandle被遗忘贴图和网格常驻不释放第二个案例来自一个3D展示项目界面里频繁切换展示物品每个物品会异步加载若干贴图和网格。测试发现运行十分钟后内存从一个比较低的水平涨到接近临界值LLM快照显示Texture2D和StaticMesh的占用异常。一开始大家认为这些资源加载后自动释放毕竟展示物品已被卸载。但用memreport对比发现Texture2D的数量随着切换次数的增加只增不减。逐帧跟踪后发现每次异步加载都创建了StreamableHandle代码只关注了加载完成回调却没有在展示结束后Release这个Handle也没有Cancel。Handle一直持有资源的强引用垃圾回收器自然不敢把这些贴图当垃圾清掉。很多团队在使用UE5的PrimaryAsset或StreamableManager时都会踩这个坑加载路径写得很顺手但生命周期收尾完全被遗忘。资源系统不像Actor那样有明确的Spawn和Destroy对称操作Handle的释放要靠开发者主动编写漏掉一次资源就常驻一份。修复建议是给临时加载和常驻缓存两种资源需求建立两条不同的代码路径。临时加载的资源明确在关闭展示时Release Handle常驻缓存则放进专门的AssetManager类里由缓存模块统一控制上限和淘汰策略。不要把两者混在一个接口里否则后期根本查不清某个资源是被谁拉住的。3.3 案例三原生容器里藏了强引用Delegate和Lambda的隐式捕获第三个案例比较隐蔽涉及战斗系统。某项目每打完一场战斗战场上的一些技能表现物没有被释放时间久了战斗场景中的Actor数量持续累积。诡异的是这些Actor没有被任何UPROPERTY引用用Reference查看器看引用链是空的。最后通过给技能表现物的BeginDestroy加调试日志发现它们根本没有进入销毁流程。再查问题出在原生C容器上。战斗开始时会往一个全局TMultiMap里注册回调用于处理伤害事件回调里绑定了一个LambdaLambda通过捕获this持有了技能Actor的强引用。这个容器不是UPROPERTY但它在原生层一直存在回调函数对象的引用关系并不被GC的对象图可见性常规扫描完全覆盖结果就是这些Actor被看不见的绳子拉住既不销毁也不崩溃。修复方式是在战斗结束时RemoveAll此容器中相关回调并把Lambda改成TWeakObjectPtr捕获判空如果回调本身不要求强持有尽量用AddWeakLambda而不是AddLambda。这个案例告诉我们引用清理不光是UPROPERTY的事原生C里的TArray、TMap、Delegate也是一等一的引用持有者。它们不会显示在常见的引用查看工具里排查成本反而更高。4. 引用链的定位方法从数据异常到代码真凶4.1 用断点、日志和引用遍历缩小范围obj list只能告诉你某个类数量异常还不能告诉你谁拿着它。下一步是找引用源。我常用的招数有三个第一在可疑类重写BeginDestroy和FinishDestroy打印对象路径和堆栈。如果对象数量异常但BeginDestroy根本不触发说明它从未进入回收流程如果触发了但数量还在涨说明销毁逻辑或引用释放有问题。第二利用ConditionalBeginDestroy的前置条件。有些老手会在可疑对象的标记阶段下断点观察IsReferenced的返回路径这需要源码级调试但对定位深水区问题非常有效。第三写一个临时调式命令遍历所有UObject找出指向可疑对象的引用者输出引用者的Class和Outer路径。这种命令在引擎层写并不复杂却能在一个小时里帮你把隐性引用挖出来。虽然看起来暴力但在UObject数量几千上万的情况下它比人工读代码快得多。4.2 把对象增长曲线和操作链路对齐当你反复操作某个功能时如果对象的增长模式是每次1基本可以断定是某个对称操作缺失。例如UI开与关、技能的创建与销毁、战斗的开始与结算只要在某一侧漏了清理就会形成稳定递增。如果对象增长是上涨一段后停滞再操作再涨则更像缓存或池子没过期例如资源异步加载后全部常驻或者对象池没有淘汰机制。这种曲线有一个特点复现操作越多越不线性很难准确预估峰值。我建议在开发阶段做一个Debug HUD页面显示几个关键类型Actor、Widget、Texture2D等的对象数量曲线。把曲线输出为CSV跑一段自动化测试回来直接和操作日志对齐往往一下就能锁定到某个模块。这个做法前期投入不大但能省下大量猜引用的时间。4.3 修复时先修生命周期语义不要只修数据有一种情况很迷惑把某个强引用改成WeakPtr内存泄漏立刻消失了对象数量也稳定下来。很多人以为问题解决了其实只是把应该清理却没清理的语义压了下去对象仍然活得比预期久只是GC不再被强引用拦住最后被回收了。在某些场景下这是可接受的但如果你明明希望对象立即退出却不退WeakPtr只会让逻辑在错误的窗口期访问一个可能失效的对象。我的原则是先问自己这个对象应该活多久如果应该活到功能结束时那就该在功能结束时明确清理强引用如果它本质上只是个短生命周期实例只是被某个缓存顺带拉住那WeakPtr是合理的防御如果它需要长期存在却被不断重新创建问题就在创建策略而不在引用类型。实际排查中很多人冲进代码就把UPROPERTY改成TWeakObjectPtr结果后续出现大量空指针崩溃。根因是你掩盖了持有者没清理的事实引用断了但业务逻辑还在依赖旧对象。优先级应该是先修复持有者的清理时机再考虑是否用WeakPtr做防守。5. 从架构层面减少GC压力别让GC扛下所有5.1 用结构体和普通C对象承载轻量数据一个经常被忽略的事实是UObject并不是免费的。每个UObject都会进入全局对象链表、带反射元数据、参与GC遍历。如果一个项目里大量的临时数据都以UObject存在GC压力会指数级上升。举个例子。某项目场景里同时存在近万个掉落物表现实例每个掉落物都是一个Actor包含一个StaticMeshComponent和一个旋转组件。这个设计的可读性确实好但从GC角度看是灾难每次GC标记都要遍历近万个Actor和它们各自的组件、引用链。后来重构时把掉落物的数据改成普通结构体数组只用一个Actor作为总管理器再根据位置批量更新InstanceMesh数据。UObject数量从一万多降到几十GC一次标记的时间直接降了一个数量级。这个经验可以推广到很多场景一次性怪物、伤害数字、技能痕迹、客户端临时状态、抽奖动画里的浮动图标这些都不一定非要做成Actor或UObject。能放进FStruct或USTRUCT的就不要套UObject。UObject应该在需要反射、序列化、蓝图访问、编辑器交互时才考虑。5.2 对象池的正确打开方式上限和淘汰比复用更重要对象池是个好工具能显著减少短期创建销毁的开销。但很多项目的对象池走到极端变成变相泄漏。比如有些池子固定预热了几百个对象却从来没有回收过闲置对象有些池子随着玩法形态不断扩池规模只增不减最终池子本身成了最大的GC压力之一。我对对象池的建议是池子要设计上限。比如伤害数字池最多200个超出上限后不新建而是从最旧的对象回收复用。闲置淘汰机制必须有。连续N分钟没有活跃使用的对象应当标记为可清理释放它占用的内存。池子持有的引用要区分强弱。长期存活的池可以持有强引用但池内的对象要能彻底重置短生命周期池建议持有弱引用同时处理对象失效后的兜底逻辑。对象池解决的是创建销毁瞬时开销GC解决的是对象总量积累。两者是不同维度的东西不要互相替代。5.3 软引用、弱引用、资产管理器的分工协作如果你还在用手写硬引用连接所有资产和逻辑对象那GC再怎么优化都治标不治本。合理的做法是把引用关系扁平化、按生命周期分层。硬引用UPROPERTY/UObject*用于这个对象存活期间被引用对象必须存在的强依赖。比如Widget持有它的数据模型、Actor持有它的主Mesh。软引用TSoftObjectPtr/TSoftClassPtr用于可能被加载但不应长时间保活的资产引用。它不会阻止GC但资产被释放后需要重新加载。弱引用TWeakObjectPtr用于我会主动判空对象死活不影响我核心逻辑的观察型引用。在资源加载层面我习惯用AssetManager统一管。核心思想是给每种资源定义明确的区域级生命周期资源类型生命周期管理策略全局UI、系统菜单资产游戏启动到结束进入DisregardForGC或常驻缓存大世界区域资产玩家进出区域时按区域加载/卸载配合World Partition战斗临时资产单场战斗时长战斗结束统一Release Handle并清理预览/展示资产打开预览到关闭打开时加载关闭时立即Release把资源分类清楚GC才能按照预期把不该活的对象回收掉。最怕的是所有资源用一种方式混着管结果GC既不知道哪些该留也不知道哪些该清。6. GC参数调优的实践经验参数只能缓解不能根治6.1 UE5中的GC相关参数对应表在完成了对象总量控制和引用清理之后如果还想进一步优化体验可以动一下GC的调度参数。注意这些参数在不同引擎版本里可能有细微差别建议改之前先到Engine/Source/Runtime/CoreUObject/Private/UObject/GarbageCollection.cpp和相关配置类里搜关键字确认你当前版本的参数名。下面是我在项目中常用到的一组对照参数作用我的建议gc.TimeBetweenPurgingPendingKillObjects两次GC之间的最短间隔默认约60秒如果项目卡顿集中在GC瞬间可适当调大降低GC频率但如果对象量在上升调大只是推迟问题gc.MaxObjectsNotConsideredByGC待清除对象数量小于该值时跳过GC适合小对象密集、每轮GC收益较低的项目值不宜过大否则内存会失控gc.IncrementalReachabilityAnalysisEnabled增量可达性分析开关UE5中引入可减少单帧峰值但会把时间摊到多帧手游需要重点观察持续帧时间gc.IncrementalReachabilityAnalysisTimeLimit每帧用于增量标记的时间上限和上一个参数配合使用按实际帧预算调整以我们项目为例曾经在手机上遇到GC单帧峰值达到80ms打开增量标记后单帧峰值降到35ms但帧率曲线从偶尔跳崖变成频繁微卡。有些玩家反而觉得更难受最后我们又把时间限调低让GC在几帧内集中完成并用后续的UI动画掩盖掉这次轻微掉帧。这说明参数调优一定要结合游戏本身的体验目标没有绝对正确的配置。6.2 把GC时机交到游戏逻辑手上引擎默认的GC触发是在主线程Tick里定期执行但它并不知道你的玩法当前是否处于关键帧。聪明的做法是在游戏里显式控制GC的触发时机。常见的安全触发点关卡切换的Loading画面期间。打开商店、仓库等非战斗UI界面时。战斗结算到下一场战斗之间。服务器返回空闲状态等待玩家操作的间隙。触发代码很简单if (GEngine) { GEngine-ForceGarbageCollection(true); }参数true表示立即执行false表示在下一帧的合适时机执行。这里有一个重要的坑不要在战斗过程中频繁调用ForceGarbageCollection。每帧调用会让大量对象在战斗中进入销毁流程造成比GC本身更明显的卡顿和资源抖动。正确的做法是在确认应当回收且当前不是关键帧时再触发。我还见过一种做法把GC触发延后到镜头切换或过场动画期间让加载动画覆盖掉卡顿。这虽然不是根治但对用户体验的提升是立竿见影的。6.3 调优后怎么验证效果调参不是调完就算要有一个明确的验证标准。我建议抓三组数据调优前同一场景、同一操作路径下的stat gc时间和帧率尖峰幅度。调优后同样的操作路径重复三次取平均值。重点观察连续运行20分钟、40分钟甚至更长时间后的变化确认为什么泄漏点已被修复。调参的效果通常表现为平均GC耗时下降、尖峰频率降低但如果对象总量还在涨运行一段时间后GC耗时依然会回来。所以参数调优只能作为配合手段排在核心问题修复之后再考虑。把参数放在最前面调相当于给漏水的水桶加个盖子——水还是会从别的地方流出去。7. 踩坑复盘那些容易弄巧成拙的优化7.1 手动GC调用拉满的连锁反应有人发现GC卡顿后第一反应是那我手动让它闲时GC不就好了。结果在Update里每几秒ForceGarbageCollection一次反而引发了更严重的连锁反应。原因很简单GC不是瞬间完成的BeginDestroy、FinishDestroy、资源卸载都要时间。频繁手动GC会让一批又一批对象同时进入销毁流程GC的Destroy阶段开销直接成为新瓶颈。我后来定了一条规矩除非你明确知道当前处于对象大量过期的时机否则不要主动调用GC。让引擎按节奏来配合准确的对象引用管理比任何手动GC都稳。7.2 把一切都改成WeakPtr导致的悬垂访问前面说过WeakPtr会掩盖生命周期语义。在项目里有时我们为了快速止血把某类对象的强引用全改成TWeakObjectPtr内存问题确实消失了但紧接着爆发出一堆访问无效对象的崩溃。原因在于WeakPtr不会阻止GC对象被回收后IsValid()就会返回false而业务代码在好几个地方都直接Foo-SomeMethod()没有判空。频繁空指针让玩家直接闪退比内存问题严重得多。正确的姿态是先用强引用理清楚生命周期再用WeakPtr做跨模块观察。任何WeakPtr在使用前都要判空并且要确认对象失效后流程应该怎么走。7.3 把GC阈值调到极端来逃避问题还有一个非常危险的做法是直接把gc.MaxObjectsNotConsideredByGC调到极大值让GC几乎不跑。效果确实好帧率曲线一路平直但内存在后台悄悄膨胀UObject越堆越多最后在一个不经意的地方OOM崩溃这类问题发布出去会非常难看。GC无论怎么调本质上是在回收频率和瞬时开销之间做权衡。你要么接受偶发的卡顿要么把对象总量压下去。不存在既完全无卡顿又无限不回收内存的方案。我见过太多项目在GC上做表面文章最后都付出了更高的维护成本。从我个人大量项目经验来看UE5 GC优化的正确顺序永远是先用数据量化卡顿和对象增长再修引用和生命周期然后考虑对象池和结构体替换最后才动参数。顺序反了往往事倍功半。如果你现在正好被GC卡顿和内存泄漏折磨不妨先花一下午把obj list和LLM的数据拉出来看到曲线被定位到的那一刻你会觉得一切排查都是有价值的。