引言
在 Unreal Engine (UE) 这样复杂且高性能的 C++ 开发环境中，自动内存管理扮演着至关重要的角色。垃圾回收器 (Garbage Collector, GC) 正是这一机制的核心，专门负责管理所有派生自 UObject 的对象的生命周期。对于实时应用程序而言，GC 的设计与实现一直是一项艰巨的工程挑战，其主要目标是避免因内存回收操作而导致的性能“停顿”或“卡顿”。
随着 Unreal Engine 的不断演进，其 GC 系统也经历了深刻的变革。UE5 标志着一个重要的转折点，系统从传统的“全局暂停”(stop-the-world) 回收模式，逐步转向了更为先进的增量式系统。这一转变的核心是为了解决长久以来困扰开发者的 GC 停顿问题。诸如增量可达性分析 (Incremental Reachability Analysis) 等现代特性的引入，正是为了在不牺牲运行时性能的前提下，实现高效、平滑的内存管理。
本报告旨在对 Unreal Engine 5.6 中的垃圾回收系统进行一次全面而深入的技术剖析。报告将从构成 GC 系统的基础框架——UObject 内存管理模型——入手，逐步深入到经典的“标记-清除”算法的具体流程，并重点阐述 UE5 中为消除性能瓶颈而引入的增量回收机制。此外，报告还将系统性地梳理性能优化策略、高级手动控制方法，以及在 UE 5.6 环境下进行 GC 问题调试与性能分析的现代化工作流程。
1. UObject 内存管理框架
要理解垃圾回收器的工作原理，首先必须掌握其赖以运作的基础架构。UE 的 GC 系统并非凭空运作，而是紧密依赖于引擎的 UObject、反射系统以及一套精心设计的引用类型。
UObject 的角色
垃圾回收机制在 Unreal Engine 中是专为继承自 UObject 的类所设计的。对于非 UObject 的 C++ 对象，开发者必须手动管理其内存，或者借助 Unreal 提供的智能指针库（如 TSharedPtr、TUniquePtr 等）来实现。引擎内部维护着一个名为 GUObjectArray 的全局数组，它像一本名册，记录了当前存在的所有 UObject 实例。每当通过 NewObject<T>() 创建一个新对象时，该对象就会被注册到这个数组中，成为 GC 系统追踪和管理的候选对象。
反射系统与 UPROPERTY
反射系统是 UE 垃圾回收机制的基石。通过 Unreal Header Tool (UHT) 在编译时生成的元数据，GC 能够在运行时动态地发现和遍历对象之间的引用关系。
UPROPERTY() 宏是开发者与 GC 系统交互最直接的方式。当一个指向 UObject 的指针成员被标记为 UPROPERTY() 时，例如 UPROPERTY() UMyObject* MyObject;，它就被视为一个“强引用”。GC 在进行可达性分析时，会识别这个引用，并确保其指向的对象不会被回收。这种强引用规则同样适用于存储在 UPROPERTY() 标记的容器中的 UObject 指针，如 TArray<UMyObject*>。
UPROPERTY() 宏的运用，在 Unreal C++ 中建立了一种根本性的二元性：指针不再仅仅是内存地址，而是被明确区分为“GC 感知”的强引用或“GC 隐形”的原始指针。这种设计迫使开发者必须在类的成员声明中，就对对象的归属权和生命周期意图做出明确的架构决策。一个未经 UPROPERTY() 标记的原始指针，实际上是在向系统声明“我不负责此对象的生命周期”，这在缺乏如 TWeakObjectPtr 等安全机制的保障下，是一个极其危险的假设。
强引用与弱引用的关键区别
理解不同类型的指针如何与 GC 系统交互，对于避免内存泄漏和悬垂指针至关重要。
- 原始指针 (危险区): 一个未经
UPROPERTY()宏标记的普通 C++ 指针（如UMyObject* MyRawPtr;）对 GC 系统是完全“隐形”的。如果它所指向的对象被 GC 回收，这个指针不会被自动置空，而是会变成一个“悬垂指针”。后续任何对该指针的解引用操作都将导致程序崩溃。 - TWeakObjectPtr (安全方案):
TWeakObjectPtr是引擎官方推荐的、用于持有非拥有性“弱引用”的方式。它具备两个核心特性：首先，它不会阻止其引用的对象被垃圾回收；其次，也是最关键的一点，当被引用的对象被销毁时，引擎会自动将所有指向该对象的TWeakObjectPtr设置为nullptr。这从根本上杜绝了悬垂指针的产生，使其成为实现可选引用或打破对象间循环依赖（可能导致内存泄漏）的理想工具。 - TSoftObjectPtr: 与
TWeakObjectPtr类似，TSoftObjectPtr也是一种弱引用，但它的独特之处在于可以指向一个当前尚未加载到内存中的资源（Asset）。这对于管理大型项目的资源加载和内存占用至关重要，允许开发者在需要时才异步加载资源。
2. 垃圾回收流程：标记-清除算法深度解析
Unreal Engine 的垃圾回收器采用的是一种标准的“标记-清除”(Mark & Sweep) 算法。这个过程虽然在概念上很直观，但其内部实现却相当精妙。以下是传统（非增量）GC 流程的详细分解。
根集：信任的起点
GC 流程的起始点是一组被称为“根集”(Root Set) 的对象。这些对象被假定为总是“存活”或“可达”的，GC 将从这些对象出发，开始其引用关系的遍历。根集的构成包括：
- 通过代码显式调用
AddToRoot()添加的对象。 - 引擎核心的单例对象。
- 当前加载的
UWorld对象。 - 存在于已加载关卡中的所有 Actor 及其组件。
阶段一：标记 (可达性分析)
这是整个 GC 流程中对性能影响最大的阶段。
- 假定皆为垃圾: 在分析开始时，GC 会遍历全局的
GUObjectArray，并将每一个UObject初始标记为“不可达”。 - 递归遍历: 随后，GC 从根集中的每一个对象开始，沿着所有强引用（即
UPROPERTY()指针或通过AddReferencedObjects函数添加的引用）进行递归遍历，访问它们引用的其他UObject。 - 标记为可达: 在遍历过程中，任何被访问到的对象，其“不可达”标记都会被清除。这些对象现在被认为是“存活”或“可达”的。这个过程会持续进行，直到从根集出发的所有引用路径都被探索完毕。
阶段二：清除 (回收与销毁)
当标记阶段完成后，GC 便进入清除阶段，处理那些仍然被标记为“不可达”的对象。
- 收集不可达对象: GC 再次遍历
GUObjectArray。任何仍持有“不可达”标记的对象都被视为垃圾。这些对象会被添加到一个待处理列表（GUnreachableObjects）中。 - 引用失效与 BeginDestroy: 引擎会对每一个不可达对象调用
ConditionalBeginDestroy()。这是对象在被彻底销毁前，开始清理自身资源的第一次机会。此阶段一个至关重要的行为是：引擎会查找整个系统中所有指向这个即将被销毁对象的UPROPERTY强引用指针和TWeakObjectPtr弱引用指针，并将它们全部设置为nullptr。这个“自动置空”的特性是 UE 内存安全的关键保障，它从根本上防止了悬垂指针的产生。 - FinishDestroy 与内存回收: 最后，通过调用
ConditionalFinishDestroy()，对象的析构函数会被执行，其占用的内存将被真正释放并归还给系统。这个销毁过程可以通过“增量清除”(Incremental Purge) 机制，将销毁操作分摊到多个帧上执行，以减轻单帧的性能压力。
GC 的清除过程不仅仅是释放内存，它更是引擎对象生命周期管理的一个主动环节。引用自动置空的特性，使得对 UObject 指针进行 IsValid() 或 if (MyObjectPtr) 的有效性检查，远比标准 C++ 中的空指针检查更为可靠。因为它不仅能处理未初始化的指针，还能正确处理那些所指对象已被 GC 销毁但内存尚未被重新分配的情况。这使得 GC 从一个单纯的内存管理器，升格为保障引擎运行时完整性与安全性的核心功能，有效减少了一类在传统 C++ 开发中极其常见且难以调试的错误。
3. UE5 中的现代 GC：通过增量回收消除停顿
尽管“标记-清除”算法行之有效，但其传统实现在实时应用中存在一个致命缺陷：由可达性分析引发的性能停顿。
问题所在：可达性分析的停顿
传统的标记阶段为了保证对象引用图的一致性，必须在一个游戏帧内完成。在一个拥有数百万 UObject 的大型项目中，这个分析过程可能耗时数十甚至数百毫秒，有时甚至达到秒级，从而导致游戏画面出现明显且不可接受的冻结。
解决方案：增量可达性分析
为了解决这一难题，UE 引入了增量可达性分析 (Incremental Reachability Analysis)。该功能最早在 UE 5.4 中作为实验性特性出现，并在 5.5/5.6 版本中逐步成熟。其核心思想是将原本在单帧内完成的可达性分析任务，拆分到多个连续的游戏帧上执行。引擎每帧只处理一部分对象的扫描工作，并严格遵守一个由控制台变量 gc.IncrementalReachabilityTimeLimit 定义的时间预算（通常为 2 毫秒），从而避免对游戏主线程造成可感知的阻塞。
关键技术：TObjectPtr 与写屏障
将分析过程时间分片引入了一个新的复杂问题：在 GC 分步进行分析的期间，游戏逻辑可能随时会修改对象引用图（例如，创建一个新的引用或断开一个旧的引用）。为了确保 GC 不会错过这些动态变化，引擎引入了 TObjectPtr<T>。
TObjectPtr<T> 是一个对原始指针的模板化封装，它为引擎实现“写屏障”(Write Barrier) 提供了基础。当增量 GC 处于激活状态时，任何对 TObjectPtr 成员的赋值操作（如 MyTObjectPtr = NewObject;）都会被引擎拦截。这个赋值操作除了完成指针的设置外，还会触发一段额外的代码，立即将被引用的新对象（NewObject）标记为可达。这样，即使这次赋值发生在 GC 的两个分析切片之间，也能保证新创建的引用关系被 GC 正确捕获，避免对象被错误地回收。
至关重要的是，为了让增量 GC 能够正确工作，项目中所有标记为 UPROPERTY 的 UObject 指针都必须从原始指针类型（如 UMyObject*）转换为 TObjectPtr<UMyObject> 类型。如果未能遵循这一规则，可能会导致对象在引用关系建立后，仍被 GC 误判为不可达，从而被过早地回收，引发严重错误。
配置与控制
要启用和配置增量 GC，需要在项目的 DefaultEngine.ini 文件中设置相应的控制台变量。
表 1: 增量 GC 控制台变量
| 控制台变量 | 描述 | 默认值 |
|---|---|---|
gc.AllowIncrementalReachability |
增量可达性分析的总开关。设置为 1 以启用。 | 0 |
gc.AllowIncrementalGather |
启用或禁用不可达对象的增量式收集。 | 0 |
gc.IncrementalReachabilityTimeLimit |
每帧用于增量 GC 任务的软时间限制（秒）。 | 0.002 (2ms) |
gc.DelayReachabilityIteration |
(用于压力测试) 将每次可达性分析的迭代延迟指定的帧数。 | 10 |
gc.VerifyNoUnreachableObjects |
(用于调试) 在分析结束后运行一个较慢的验证过程，确保没有存活对象引用了即将被回收的对象。 | 0 |
gc.ContinuousIncrementalGC |
(用于压力测试) 在上一个增量 GC 周期结束后，立即开始一个新的周期。 | 0 |
4. 性能优化策略
优化 GC 性能是一个系统性工程，涉及从编码习惯到引擎高级特性的多个层面。
基本原则：减少 UObject 数量
最直接也是最有效的优化手段，就是从源头上减少 GC 的工作量。可达性分析的成本与场景中 UObject 的数量及其引用关系的复杂度成正比。以下是一些切实可行的建议：
- 使用 USTRUCT: 对于纯粹的数据容器，如果不需要
UObject的反射、网络复制或垃圾回收等高级功能，应优先使用USTRUCT。结构体的内存开销远小于UObject，且其生命周期由其所有者直接管理，不给 GC 增加负担。 - 代码转换: 将仅包含数据或静态函数的蓝图转换为 C++ 类或蓝图函数库。每个蓝图类实例本身都是一个
UObject，存在一定的开销。对于无需实例化或状态的逻辑，使用更轻量级的实现可以减少不必要的UObject数量。 - 对象池: 对于那些频繁创建和销毁的对象（如子弹、特效），应采用对象池 (Object Pooling) 技术。通过复用预先分配的对象，而不是在需要时创建、在用完后销毁，可以极大地降低
UObject的创建和销毁频率，从而显著减轻 GC 的压力。
引擎级优化 (项目设置)
Unreal Engine 在项目设置中提供了一系列开关，用于调整 GC 的行为以适应不同项目的需求。
- 并行垃圾回收: 启用
Allow Parallel GC(gc.AllowParallelGC=1) 允许引擎使用多个工作线程来并行执行部分 GC 任务，尤其是可达性分析的遍历过程，这在多核 CPU 上能有效缩短 GC 的总耗时。 - 多线程销毁: 启用
Multithreaded Destruction Enabled(gc.MultithreadedDestructionEnabled=1) 会将对象的FinishDestroy阶段（即实际的内存释放操作）卸载到一个工作线程上执行，从而分担游戏主线程的压力。
表 2: 垃圾回收项目设置 (DefaultEngine.ini)
| 分类 | 设置 | 描述 |
|---|---|---|
| 通用 (General) | TimeBetweenPurgingPendingKillObjects |
等待清除待销毁对象引用的时间间隔（秒）。 |
FlushStreamingOnGC |
若启用，每次触发 GC 时都会刷新流式加载系统。 | |
NumberOfRetriesBeforeForcingGC |
当工作线程正在修改 UObject 状态时，GC 可被跳过的最大次数。0 表示从不强制执行。 | |
| 优化 (Optimization) | AllowParallelGC |
若启用，GC 将使用多线程。 |
IncrementalBeginDestroyEnabled |
若启用，引擎将使用每帧的时间限制来增量式地销毁对象。 | |
MultithreadedDestructionEnabled |
若启用，引擎将在工作线程上释放对象内存。 | |
CreateGarbageCollectorUObjectClusters |
若启用，引擎将尝试创建对象集群以提升 GC 性能。 | |
AssetClusteringEnabled |
是否允许资源文件创建 Actor 集群用于 GC。 | |
ActorClusteringEnabled |
是否允许关卡创建 Actor 集群用于 GC。 | |
BlueprintClusteringEnabled |
是否允许蓝图类创建 GC 集群。 | |
UseDisregardForGCOnDedicatedServers |
若禁用，DisregardForGC 优化将在专用服务器上被禁用。 |
|
PendingKillEnabled |
若启用，标记为 PendingKill 的对象将由 GC 自动置空并销毁。 |
|
MinimumGCClusterSize |
GC 集群的最小尺寸。 | |
MaximumObjectCountNotConsideredByGC |
GC 不予考虑的最大对象数量（仅在打包版本中有效）。 | |
SizeOfPermanentObjectPool |
永久对象池的大小（字节，仅在打包版本中有效）。 | |
MaximumNumberOfUObjects... |
分别设置打包游戏和编辑器游戏中可存在的最大 UObject 数量。 | |
| 调试 (Debug) | VerifyFGCObjectNames |
验证所有 FGCObject 派生类是否重写了 GetReferencerName()。 |
VerifyUObjectsAreNotFGCObjects |
当 UObject 派生类同时派生自 FGCObject 时发出警告。 |
高级技术：对象集群
对象集群 (Object Clustering) 是一种高级优化技术，其核心思想是将大量相关的 UObject（例如一个复杂 Actor 的所有组件）逻辑上组合成一个“集群”。当 GC 在可达性分析中发现集群的根对象是可达的时，它可以一次性地将集群内所有其他成员都标记为可达，而无需对每个成员进行深度递归扫描，从而大幅提升效率。
实现集群需要两步：首先，在类定义中重写虚函数 virtual bool CanBeInCluster() 并返回 true；然后，在根对象上调用 CreateCluster() 函数来自动创建集群。
然而，集群并非万能药。它在显著降低可达性分析耗时的同时，可能会大幅增加“标记对象为不可达”(MarkObjectsAsUnreachable) 阶段的耗时。其实际性能收益并非绝对，强烈依赖于具体的使用场景，必须通过性能分析来验证。在开发版本中，由于额外的验证开销，启用集群甚至可能导致性能下降。
永久对象的优化：DisregardForGC
对于那些在程序启动时创建、并且在整个生命周期内都存在的对象（如各种管理器单例），引擎提供了一种名为 DisregardForGC 的特殊优化。被标记为此状态的对象将被 GC 完全忽略，不会进入可达性分析的范围，从而为每次 GC 节省少量时间。
使用此优化时必须注意一个重要的警告：一个 DisregardForGC 对象不能安全地持有对一个普通、可被回收对象的强引用。因为前者永远不会被 GC 扫描，所以它持有的引用无法保护后者不被回收。一旦后者被回收，前者中的指针就会在不被置空的情况下变成悬垂指针。在这种情况下，必须使用 TWeakObjectPtr 来持有引用。
Unreal Engine 中的 GC 优化是一场关于权衡与分析的博弈，不存在一劳永逸的“银弹”设置。启用并行 GC 可能会引入线程同步的开销，而对象集群则可能将性能成本从一个 GC 阶段转移到另一个阶段。最佳策略高度依赖于特定项目的对象使用模式。因此，专业的优化流程并非简单地启用所有优化选项，而是首先利用分析工具（如后文将介绍的 Unreal Insights）来诊断 GC 的具体行为，形成假设（例如，“我的可达性分析耗时过高是因为存在大量细碎的组件”），然后针对性地应用某项优化（如对象集群），最后再次进行分析以验证优化效果。这是一个基于证据、不断迭代的过程。
5. 高级 GC 主题与手动控制
除了自动化的回收流程，Unreal Engine 还提供了一系列接口，允许开发者在更深的层次上与 GC 系统交互，以满足特定的高级需求。
将非 UObject 集成到 GC 中：FGCObject
在某些场景下，一个普通的 C++ 类（非 UObject）可能需要持有一个 UObject 的强引用，并确保该 UObject 不被回收。FGCObject 正是为此而生。通过让普通 C++ 类继承自 FGCObject 并重写 AddReferencedObjects(FReferenceCollector& Collector) 虚函数，该类就可以向 GC 系统“报告”它所引用的 UObject。
以下是一个典型的实现示例：
C++
#include "UObject/GCObject.h"
class FMyNormalClass : public FGCObject
{
public:
// 需要被保护不被GC的UObject指针
UObject* SafeObject;
FMyNormalClass(UObject* Object) : SafeObject(Object) {}
// 重写此函数以向GC报告引用
virtual void AddReferencedObjects(FReferenceCollector& Collector) override
{
Collector.AddReferencedObject(SafeObject);
}
// 还需要一个虚析构函数
virtual ~FMyNormalClass() {}
};
在这个例子中，每当 GC 运行时，它都会调用 FMyNormalClass 实例的 AddReferencedObjects 方法。通过 Collector.AddReferencedObject(SafeObject)，SafeObject 被标记为可达，从而避免了被回收。
在 UObject 内部手动添加引用：AddReferencedObjects
UObject 派生类自身也可以重写 AddReferencedObjects 函数。这种情况虽然不如 UPROPERTY() 常见，但在某些特定场景下是必需的。例如，当一个 UObject 需要通过一个未标记为 UPROPERTY 的原始 C++ 指针（可能存储在某个复杂数据结构中）持有对另一个 UObject 的强引用时，就必须通过重写此函数来手动将该引用告知 GC。
挂接到 GC 流程：FCoreUObjectDelegates
引擎的全局委托系统 FCoreUObjectDelegates 提供了一系列钩子，允许开发者在引擎的关键事件点执行自定义逻辑。与 GC 相关的委托包括：
FCoreUObjectDelegates::GetPreGarbageCollectDelegate(): 在 GC 周期即将开始时触发。FCoreUObjectDelegates::GetPostGarbageCollectDelegate(): 在 GC 完成后触发。
开发者可以绑定自定义函数到这些委托上，以实现 GC 前后的日志记录、状态清理或其他同步操作。以下是一个示例用法，展示了如何绑定一个函数：
C++
#include "UObject/CoreUObjectDelegates.h"
void MySystem::Initialize()
{
// 绑定到GC开始前的委托
FCoreUObjectDelegates::GetPreGarbageCollectDelegate().AddRaw(this, &MySystem::OnPreGarbageCollect);
}
void MySystem::OnPreGarbageCollect()
{
// 在这里执行GC开始前的自定义逻辑
UE_LOG(LogTemp, Log, TEXT("Garbage Collection is about to start."));
}
显式触发垃圾回收
在某些情况下，开发者可能希望手动触发一次完整的垃圾回收。
- 控制台命令: 在开发版本中，可以通过控制台命令
obj gc来强制执行一次完整的 GC 清除。 - C++ API: 在 C++ 代码中，可以通过
GetWorld()->ForceGarbageCollection(true)来编程触发。
强制 GC 应当谨慎使用，因为它会引发一次显著的性能停顿。合适的时机通常是在非游戏性关键阶段，例如关卡切换时的加载界面，或者明确知道有大量内存可以被一次性回收的场景。
6. 在 UE 5.6 中调试与分析 GC
诊断和解决 GC 相关问题是内存优化的关键环节。UE 5.6 提供了一套从简单到复杂的工具链来应对这一挑战。
初步调查：控制台命令
- memreport -full: 这是排查内存问题的首选命令。它会生成一份详细的内存使用快照，其中包含了所有
UObject类的实例数量和内存占用。通过分析这份报告，可以快速定位哪些类型的对象占用了超出预期的内存。 - obj list: 一个更轻量级的命令，用于快速列出当前存在的对象实例，适合进行快速检查。
追踪引用泄漏：找到根源
调试 GC 问题的核心，往往是回答“为什么这个对象还存在于内存中？”这个问题。
- 引用查看器 (Reference Viewer): 在内容浏览器中右键单击任一资源，选择“引用查看器”，可以打开一个可视化界面，清晰地展示出该资源引用了哪些其他资源，以及它被哪些资源所引用。这对于理解静态的资源依赖关系非常有用。
- obj refs 命令: 这是一个功能强大的命令行工具。通过执行
obj refs name=<ObjectName> shortest，可以追踪并打印出从根集到指定对象的最短引用链。这条引用链会精确地揭示出该对象因何被判定为“可达”，从而直接定位到导致其无法被回收的源头。
使用 Unreal Insights 进行深度分析
对于动态和复杂的内存问题，Unreal Insights 是目前最强大的分析工具。
-
启动与设置: 要进行内存分析，必须在启动项目时附加特定参数以开启内存追踪，例如：
-trace=default,memory,assetmetadata。这会生成一个可供 Unreal Insights 打开的.utrace文件。 -
Memory Insights 面板:
- 时间轴视图: 在时间轴上，可以清晰地看到 GC 事件的发生点，并将其与内存总量的下降以及帧时间的尖峰进行关联分析，直观地评估 GC 对性能的影响。
- 调查面板: 这是 Memory Insights 最核心的功能。它提供了一套查询系统，用于发现内存泄漏。例如，可以设置时间点 A 和 B（如打开和关闭一个 UI 界面），然后使用“增长”(Growth) 查询，找出在这段时间内被分配但没有被释放的所有对象，从而精确定位泄漏源。
- 调用堆栈: Memory Insights 会为每一次内存分配记录完整的调用堆栈。这意味着开发者可以从一次可疑的内存分配，直接追溯到引发该分配的具体代码行，极大地提升了调试效率。
现代化的内存调试工作流程已经从基于文本的静态快照分析（如 memreport 和 obj refs）转向了使用 Unreal Insights 进行的交互式、可视化的动态分析。虽然控制台命令对于快速检查和定位特定对象的静态引用链仍然非常有价值，但 Memory Insights 提供了一个基于时间的、全局的视角。这种能力对于理解动态内存行为、瞬时内存分配以及那些并非由单一静态引用链导致的复杂泄漏问题，要强大得多。掌握 Unreal Insights 不再是高级开发者的专属技能，它代表了解决内存问题方法的范式转变。
UE 5.6 的具体情况
虽然 UE 5.6 的官方发布说明中较少直接提及 GC 的重大改动，但引擎的优化是持续进行的。性能分析显示，5.6 版本在多个系统中实现了内存占用降低，例如 PCG 和 UMG，并且核心的 UObjectHash 实现获得了约 20% 的内存削减，这些都间接减轻了 GC 的负载。此外，5.6 的更新周期中修复了一些与 GC 相关的特定 bug，如“在垃圾回收时 FPCGCreateSplineElement 崩溃”以及在打包过程中 GUnreachableObjects 数组的异常问题，这表明 GC 系统仍在活跃的开发和完善之中。
结论
Unreal Engine 5.6 的垃圾回收系统是一个复杂而强大的自动化内存管理框架。其核心建立在 UObject 与 UPROPERTY 构成的反射系统之上，通过经典的“标记-清除”算法来管理对象生命周期。UE5 时代最重要的进步，无疑是从传统“全局暂停”模式向增量回收的演进。以 TObjectPtr 和写屏障技术为支撑的增量可达性分析，从根本上解决了长期困扰开发者的 GC 性能停顿问题，是开发大型、高画质游戏的关键保障。
实现最佳的 GC 性能并非孤立地调整几个参数就能达成，它是一个系统性工程的成果。卓越的 GC 表现源于良好的整体内存纪律：从设计上减少不必要的 UObject 分配，为不同场景选择合适的数据结构（UObject vs USTRUCT），并充分利用引擎提供的流式加载、对象池等特性。UE 5.6 中对各个模块进行的内存优化，也印证了这一整体性原则。
对于工作在 UE 5.6 环境下的开发者而言，以下几点是关键的最佳实践：
- 拥抱 TObjectPtr: 全面将
UPROPERTY指针转换为TObjectPtr，以充分利用增量 GC 带来的性能优势。 - 以分析驱动优化: 避免盲目开启所有优化选项。使用 Unreal Insights 作为主要的性能分析工具，诊断具体的性能瓶颈，并基于数据做出优化决策。
- 从源头控制: 始终将减少
UObject的创建和销毁频率作为首要优化目标。优先考虑对象池、使用结构体等成本更低的方案。 - 善用工具: 熟练运用
obj refs命令和引用查看器来快速定位引用泄漏，将它们作为日常开发中的代码健康检查工具。
通过深入理解 GC 的工作原理，并结合现代化的分析工具与优化策略，开发者可以有效地驾驭 Unreal Engine 的内存管理系统，从而打造出运行流畅、性能稳定的高品质项目。
