1
// 这是 UE C++ 中最常见的"不要把两套体系混在一起"的场景
2

3
// ✗ 绝不这样做：
4
UCLASS()
5
class UMyComponent : public UActorComponent { /* ... */ };
6

7
TSharedPtr<UMyComponent> CompPtr = MakeShared<UMyComponent>();
8
// ↑ 编译可能通过，但后果严重：
9
//   1. UMyComponent 是 UObject，必须由 GC 管理（NewObject / CreateDefaultSubobject）
10
//   2. TSharedPtr 的引用计数和 GC 的标记-清扫是完全独立的两套系统
11
//   3. GC 不知道 TSharedPtr 持有这个 UObject 的引用 → 可能 GC 误回收
12
//   4. TSharedPtr 析构时会尝试 delete → UObject 的析构必须走 GC 路径
13
//      → 直接 delete UObject 是 UB / 崩溃
14

15
// ✓ UObject 正确方式：
16
UPROPERTY()
17
UMyComponent* Comp;  // GC 通过 UPROPERTY 追踪引用
18
// 或
19
TWeakObjectPtr<UMyComponent> WeakComp;  // 弱引用，不阻止 GC
20

21
// ✓ 非 UObject 正确方式：
22
struct FMyData
23
{
24
    int32 Value;
25
    TArray<float> Buffer;
26
};
27
TSharedPtr<FMyData> Data = MakeShared<FMyData>();  // OK，FMyData 不是 UObject

1
// ===== 创建 =====
2
// std
3
auto sp1 = std::make_shared<MyClass>(arg1, arg2);
4

5
// UE — 推荐：MakeShared（等价 make_shared）
6
TSharedPtr<FMyData> SP1 = MakeShared<FMyData>(Arg1, Arg2);
7

8
// UE — 不推荐：从裸指针构造（需要引用控制器，May导致双重释放）
9
FMyData* Raw = new FMyData();
10
TSharedPtr<FMyData> SP2 = MakeShareable(Raw);
11
//   ↑ MakeShareable 包裹已有的裸指针。注意——一旦交给 TSharedPtr，
12
//     不要再通过裸指针手动 delete！
13

14
// ===== 引用计数 =====
15
int32 Count = SP1.GetSharedReferenceCount();  // ≈ use_count()
16
bool bUnique = SP1.IsUnique();                // 引用计数 == 1 ?
17

18
// ===== 解引用 =====
19
SP1->Value = 42;                     // 和 std::shared_ptr 一样
20
(*SP1).Value = 42;
21
FMyData& Ref = *SP1;
22

23
// ===== 获取裸指针 =====
24
FMyData* Raw = SP1.Get();            // = get()
25

26
// ===== 重置 =====
27
SP1.Reset();                         // 释放所有权，引用计数 -1
28
SP1 = nullptr;                       // 同上
29

30
// ===== 比较 =====
31
if (SP1 == SP2) { /* 比较内部裸指针 */ }
32
if (SP1.IsValid()) { /* 等价于 SP1.Get() != nullptr */ }
33
// ⚠️ IsValid() 只检查是否为 nullptr，不涉及 GC！（区别于 UObject 的 IsValid）
34

35
// ===== 转换为 TSharedRef =====
36
TSharedRef<FMyData> Ref = SP1.ToSharedRef();  // ⚠️ SP1 为 null 时会 断言崩溃

1
// ⚠️ 关键：TSharedPtr 默认不是线程安全的！
2

3
// UE 的 TSharedPtr 提供两种模式（ESPMode 枚举中只有这两个值）：
4
// ESPMode::NotThreadSafe  — **默认值**。引用计数使用普通整数操作（非原子）
5
// ESPMode::ThreadSafe     — 显式线程安全（引用计数使用原子操作）
6

7
// ==== 默认行为：NotThreadSafe ====
8
TSharedPtr<FMyData> DefaultPtr = MakeShared<FMyData>();
9
// ↑ 默认使用 ESPMode::NotThreadSafe！
10
//   引用计数使用普通整数加减，不是原子操作
11
//   仅在 GameThread 使用是安全的，跨线程传递会导致引用计数竞争 → 崩溃或泄漏
12
//   这是为了 GameThread 上处理海量无并发需求数据时的终极性能
13

14
// ==== 跨线程共享时，必须显式声明 ThreadSafe ====
15
TSharedPtr<FMyData, ESPMode::ThreadSafe> ThreadSafePtr = MakeShared<FMyData>();
16
// ↑ 引用计数使用原子操作，可安全跨线程传递
17
//   和 std::shared_ptr 行为一致（std::shared_ptr 的引用计数始终是原子的）
18

19
// ==== 对比 std::shared_ptr ====
20
// std::shared_ptr 的引用计数始终使用原子操作，无需用户选择
21
// TSharedPtr 把选择权交给开发者——默认非原子以获得 GameThread 最佳性能，
22
// 跨线程时再显式开启原子操作。这是 UE 对游戏引擎性能极致追求的体现
23

24
### 5.2.3 MakeShared vs MakeShareable —— 内存布局与分配次数
25

26
```cpp
27
// ==== MakeShared<T>(Args...) —— 一次分配（推荐）====
28
TSharedPtr<FMyData> P1 = MakeShared<FMyData>(Arg1, Arg2);
29

30
// 内存布局（一次 Malloc）：
31
// ┌──────────────────────────────────────┐
32
// │  FSharedReferencer (控制块)          │ ← 引用计数 + 弱引用计数
33
// │  FMyData (对象本身)                  │ ← 构造在此连续内存中
34
// └──────────────────────────────────────┘
35
// 优势：一次分配、连续内存（缓存友好）、无需额外对齐
36

37
// ==== MakeShareable(RawPtr) —— 两次分配（不推荐）====
38
FMyData* Existing = GetSomeExistingObject();
39
TSharedPtr<FMyData> P2 = MakeShareable(Existing);
40

41
// 内存布局（两次 Malloc）：
42
// ┌──────────────────┐    ┌──────────────────────┐
43
// │  FMyData (堆上)   │    │  FSharedReferencer    │ ← 独立分配的引用控制块
44
// │  (用户手动 new)   │    │  (MakeShareable 内部分配) │
45
// └──────────────────┘    └──────────────────────┘
46
// 劣势：两次分配 + 内存碎片 + 两次解引用（性能更差）
47

48
// ⚠️ 前提：Existing 的生命周期尚未被任何其他机制管理
49
// ⚠️ 一旦交给 TSharedPtr，永远不要再手动 delete
50

51
// ==== ⚠️ 致命陷阱：同一个裸指针被 MakeShareable 包裹两次 ====
52
FMyData* Raw = new FMyData();
53
TSharedPtr<FMyData> PtrA = MakeShareable(Raw);  // 控制块 A，引用计数 = 1
54
TSharedPtr<FMyData> PtrB = MakeShareable(Raw);  // 控制块 B，引用计数 = 1
55
// ✗ 工业界致命 "屠夫代码"！
56
// 原因：PtrA 和 PtrB 各自创建了完全独立的引用计数控制块。
57
// 当 PtrA 引用计数归零 → 释放 Raw → PtrB 变成野指针！
58
// 当 PtrB 引用计数也归零 → 再次 Free 同一块内存 → Double Free → 闪退！
59
//
60
// 解决：永远只包裹同一个裸指针一次。如果需要共享，拷贝已有的 TSharedPtr：
61
TSharedPtr<FMyData> PtrB_Safe = PtrA;  // 共享同一个控制块，引用计数正确 +1
62

63
// MakeShareable + Deleter —— 自定义析构行为
64
FILE* FileHandle = fopen("data.bin", "rb");
65
TSharedPtr<FILE> FilePtr = MakeShareable(FileHandle, [](FILE* f) {
66
    if (f) fclose(f);  // 引用计数归零时自动 fclose
67
});

1
// UE 所有内存分配最终经过 GMalloc（全局分配器单例）
2
// 等价于 C 的 malloc/free，但增加了 UE 的追踪和调试层
3

4
// ===== 基础分配 =====
5
void* Ptr = FMemory::Malloc(1024);            // 等价 malloc(1024)
6
void* Ptr2 = FMemory::Malloc(1024, 16);      // 指定 16 字节对齐
7
FMemory::Free(Ptr);                           // 等价 free(Ptr)
8

9
void* Ptr3 = FMemory::Realloc(Ptr2, 2048);   // 等价 realloc
10
int32 Size = FMemory::GetAllocSize(Ptr3);     // 查询分配的字节数
11

12
// ===== GMalloc 不是固定的——不同平台有不同实现 =====
13
// Windows (UE5.3+): FMallocMimalloc（微软 Mimalloc，EPIC 官方默认，替代了 Binned2/Binned3）
14
// Console: FMallocBinned3 或平台特定实现
15
// Mobile: FMallocBinned3（低碎片分级分配器，适合内存受限环境）
16
// 编辑器: 大厂生产线默认启用 Mimalloc 或 TBB 以获得更好的多线程分配性能
17

18
// 你可以通过命令行参数切换：
19
// -Malloc=Ansi     → 标准 malloc（调试用）
20
// -Malloc=Binned3  → 分级分配器（适合移动端/内存受限平台）
21
// -Malloc=Stomp    → 内存越界检测分配器（开发用，每个分配加哨兵）
22
// -Malloc=Mimalloc → 微软 mimalloc（Windows 默认，高性能多线程分配）

1
// 帧分配器的核心思想：线性栈分配 + RAII 标记回退
2
// → 无碎片、极快、无锁
3

4
// ===== 底层机制：FMemMark（不是"帧结束"这么简单）=====
5
// FMemStack 的内存不是按帧自动回收的——它的生命周期由 FMemMark 控制。
6
// FMemMark 是一个 RAII 对象：构造时记录当前栈顶位置，析构时回退到该位置。
7

8
void SomeGameSystemUpdate()
9
{
10
    FMemMark Mark(FMemStack::Get());  // ← 记录当前栈顶
11
    //    ↑ RAII 标记：离开作用域时自动 Pop()
12

13
    // 在此作用域内的所有 TMemStackAllocator 分配都在帧栈上进行：
14
    {
15
        TArray<int32, TMemStackAllocator<>> TempIndices;
16
        TempIndices.Add(42);
17
        // TempIndices 的内存来自 FMemStack 的当前栈位置
18
    }  // ← TempIndices 析构，但内存 没有立即释放！
19

20
    // ... 更多帧栈分配 ...
21

22
}  // ← 离开 FMemMark 作用域 → Mark 析构 → 栈顶回退
23
   //    FMemStack 的栈指针直接回到 Mark 记录的位置
24
   //    上面所有 TMemStackAllocator 分配的内存"瞬间"失效
25

26
// ⚠️ 致命陷阱：跨 FMemMark 持有引用
27
// 如果 TArray<T, TMemStackAllocator<>> 离开了声明它的 FMemMark 作用域，
28
// 其内部指针指向的内存已经被后续分配覆盖 → 内存踩踏！
29
// → TMemStackAllocator 的容器绝不能作为返回值或存储到成员变量中。
30

31
// ===== 在引擎中的实际应用 =====
32
// 引擎在每个 Tick 的最外层放置了 FMemMark
33
// → 所以你看到的"帧内临时数据自动回收"是 FMemMark 在 Tick 外层的效果
34
// → 本质上不是"帧"回收了内存，而是 FMemMark::Pop() 回退了栈顶
35

36
// ===== 分配器选择指南 =====
37
// 默认堆分配      → 生命周期超过当前帧的对象
38
// TInlineAllocator → 小数组优化（见 Ch4 4.2.3）
39
// TMemStackAllocator → 当前 FMemMark 作用域内的临时数据（最快但最受限）

1
// 场景：子弹、粒子、UI 元素——每帧大量创建和销毁
2
// 解决方案：对象池（Object Pool），复用而非重新分配
3

4
// UE 的 Core/Containers 模块中没有名为 TObjectPool 的通用公共容器。
5
// 引擎内部针对特定场景（如 TGraphTask、渲染命令）使用固定大小分配器，
6
// 但对非 UObject 结构体的通用对象池，通常自行实现：
7

8
// ==== 轻量级对象池（基于 TArray + 预分配）====
9
template<typename T>
10
struct FObjectPool
11
{
12
    TArray<T> Pool;
13
    TArray<bool> InUse;
14
    int32 Capacity;
15

16
    FObjectPool(int32 InCapacity) : Capacity(InCapacity)
17
    {
18
        Pool.SetNum(Capacity);
19
        InUse.SetNumZeroed(Capacity);
20
    }
21

22
    T* Allocate()
23
    {
24
        for (int32 i = 0; i < Capacity; ++i)
25
        {
26
            if (!InUse[i])
27
            {
28
                InUse[i] = true;
29
                Pool[i] = T{};  // 重置状态
30
                return &Pool[i];
31
            }
32
        }
33
        return nullptr;  // 池耗尽——扩容或等待
34
    }
35

36
    void Free(T* Ptr)
37
    {
38
        int32 Idx = static_cast<int32>(Ptr - Pool.GetData());
39
        if (Idx >= 0 && Idx < Capacity) { InUse[Idx] = false; }
40
    }
41
};
42

43
// 使用：
44
FObjectPool<FMyProjectileData> ProjectilePool(100);
45

46
FMyProjectileData* SpawnProjectile()
47
{
48
    FMyProjectileData* Data = ProjectilePool.Allocate();
49
    return Data;  // 从预分配的池中获取，零 new/delete
50
}
51

52
void DeSpawnProjectile(FMyProjectileData* Data)
53
{
54
    ProjectilePool.Free(Data);  // 归还池中，不释放内存
55
}
56

57
// ==== 更高效：TFixedSizeAllocator（引擎内部固定大小分配器）====
58
// 引擎在 TGraphTask、渲染命令等高频分配场景中使用 TFixedSizeAllocator，
59
// 它是基于单链表空闲链的固定大小对象池，远比通用 malloc 快。
60
// 对于日常业务开发，上面基于 TArray 的轻量池已足够覆盖绝大多数场景。
61

62
// 对于 UObject，不能直接用对象池（因为 GC 干扰），
63
// 但可以用类似的"标记为不活跃 + 重新初始化"的模式。
64
// UObject 的对象池通常通过 UActorComponent 的子对象缓存实现。

1
// ===== 控制台命令 =====
2
// stat memory        → 实时内存统计
3
// memreport -full    → 完整内存报告（输出到 Saved/Profiling/）
4
// obj list           → 列出所有 UObject（按类分组）
5
// obj refs Name=XXX  → 查看某个对象的引用链
6

7
// ===== 代码级内存追踪 =====
8
// 标记一个分配用于追踪：
9
void* Ptr = FMemory::Malloc(1024, 16);
10
FMemory::RegisterFreeCallback([](void* Ptr, uint64 Size) {
11
    UE_LOG(LogTemp, Log, TEXT("Freed %llu bytes at %p"), Size, Ptr);
12
});
13

14
// ===== MallocStomp —— 内存越界检测 =====
15
// 启动参数：-Malloc=Stomp
16
// 在每个分配的尾部放置哨兵值，释放时检查是否被破坏
17
// → 如果你的代码写越界了，Stomp 会在 free 时断言崩溃，精确定位

1
// 问题 1：UObject 泄漏
2
// 症状：关卡切换后，UObject 数量只增不减
3
// 排查：
4
//   - obj list 看哪个类数量异常多
5
//   - obj refs 查看是谁在持有引用
6
//   - 检查是否有对象 AddToRoot() 后忘了 RemoveFromRoot()
7
//   - 检查是否有 UPROPERTY 循环引用阻止了 GC
8

9
// 问题 2：非 UObject 泄漏
10
// 症状：进程内存持续增长，但 obj list 正常
11
// 排查：
12
//   - 搜索代码中所有 FMemory::Malloc 没有对应 Free 的地方
13
//   - 搜索代码中所有 TSharedPtr / TUniquePtr 的使用
14
//   - 注意：TSharedRef 的循环引用和 TSharedPtr 一样会泄漏
15

16
// 问题 3：野指针访问（UObject 被 GC 回收后仍被访问）
17
// 症状：随机崩溃，崩溃栈和崩溃场景毫无关联
18
// 排查：
19
//   - 搜索所有不加 UPROPERTY 的 UObject* 成员变量
20
//   - 对可疑引用改用 TWeakObjectPtr，配合 IsValid() 断言
21
//   - 开启 GC 日志：-LogGarbage 启动参数