游戏中的内存管理

1. 为什么游戏要自己管内存

• 内存鸿沟：CPU 与内存的速度差距催生了寄存器、多级缓存和 NUMA；对游戏程序员最重要的结论是"数据要连续、紧凑、顺序访问；热循环的代码要小"。见 计算机硬件与内存层次。GEA 举例 PS3 上一次缓存未命中相当于执行数千条指令（运行时对象模型架构）。
• 堆分配慢：通用分配器要处理任意大小的请求，GEA 还称 malloc/free 在多数系统上要切换到内核态（原书问题：现代分配器多数请求在用户态完成，只在扩展堆或大块分配时才做系统调用，详见该页）。GEA 的经验法则是"尽量少做堆分配，绝不在紧密循环里做堆分配"。见 自定义内存分配器。
• 碎片与主机：PS5 与 Xbox Series X/S 支持虚拟地址重映射，但不像 PC 那样自动换页到磁盘，开发者面对固定数量的 RAM，必须自己实现流送。见 自定义内存分配器。
• 布局本身：对齐与填充、虚表指针都会影响对象大小和缓存利用，见 C++ 内存布局与对齐。

2. 按生命周期选分配器

另一种极端是根本不在游戏中动态分配：载入世界块时生成全部对象，由编辑器离线分配，内存完全可预测，但策划必须预估每种对象的数量（"游戏对象守恒定律"）。见 游戏世界的加载与流送。

3. 碎片：避免、容忍或整理

• 避免：栈天然免疫碎片；池虽有碎片，但因所有块等大，不会因找不到连续块而提前耗尽。
• 整理：把已分配块下移填洞，每帧只移动少量块以摊销成本；难点是修正指向被移动块的指针。
• 引用方式决定能否整理：裸指针无法配合重定位；智能指针（如全局链表）或句柄（不可重定位的指针表的索引，带唯一 id 防止槽位复用）可以。Naughty Dog 的所有引擎都支持碎片整理，尽可能用句柄，并因此在并发更新时把"解引用句柄"当作检测对象交互的时机。见 自定义内存分配器、游戏对象引用与查询 与 游戏对象并发更新。

4. 资源与世界：引用计数、分块与流送

• 引擎保证每个资源在内存中只有一份；卸载时机比加载难，跨关卡共享的资源用引用计数避免"卸了又载"。资源可按段（主内存、显存、临时、调试）组织，按等大块分配以免碎片。见 资源管理器。
• 世界流送的目标是"边玩边载"并消除碎片：从一关一载、气闸，到 Naughty Dog 的细粒度块 + 加载区域；PS5 的 AMPR 把资产映射到预留的连续虚拟地址范围，流出时只需取消映射。见 游戏世界的加载与流送 与 引擎文件系统与异步文件读写。
• 共享不变数据：享元把内在状态（网格、纹理）共享给大量实例，是另一种省内存手段，见 享元模式。

5. 访问模式：让数据为 CPU 排队

• 把同类组件放进连续数组、活跃对象排在前面、冷热数据分离；以属性为中心的对象模型和 MassEntity 都采用 SoA 式布局。见 数据局部性 与 运行时对象模型架构。
• 容器的选择要同时看大 O 和内存布局，引擎常为避免动态分配而自研容器。见 容器与哈希表。
• 批量更新之所以快，部分原因正是子系统能把每对象数据放在一段连续内存里，见 游戏对象的实时更新。

6. UE5 的做法：GC 与智能指针

• UObject 由标记-清除式的可达性分析管理，"谁持有 UPROPERTY 引用"决定对象活多久；GC 可能造成卡顿，规避手段包括簇、调整清理间隔、对象池和增量可达性分析。见 垃圾回收与对象生命周期。
• 非 UObject 用 TSharedPtr/TUniquePtr 等，UObject 指针属性推荐 TObjectPtr；这与 GEA "远离智能指针，非用不可就用成熟实现"的建议形成对照，两种观点并列在 智能指针与 TObjectPtr。
• 在有 GC 的环境里，对象池仍可用来避免分配和回收卡顿，但也可能让本该回收的对象一直存活，见 对象池。

7. 没有度量就没有管理

• 只包装 malloc/new 不够：第三方库的分配、显存、以及每个自定义分配器内部的分配都要追踪；Naughty Dog 引擎有通用堆、对象堆、关卡加载堆、单帧栈、显存分配器、调试堆等。工具应给出各分配器/系统的高水位线、运行时内存 HUD，并在开发机上超出零售限制时醒目提示。见 游戏内性能与内存剖析。
• 这些内存策略在整个引擎运行时结构中的位置见 引擎运行时架构总览。