Unreal多线程编程指南：从FRunnable到Async的安全并发实践

做C++游戏开发的，接触Unreal之后最先不习惯的，可能就是“线程不能随便开”。在传统C++项目里写std::thread、std::async很自然，但在Unreal里，你要是真拿std::thread去跑一个循环，然后在这个线程里碰一下UObject、调一下引擎的API，等来的基本就是崩溃、卡死、随机黑屏三件套。Unreal不是不支持多线程，它不但支持，而且抽象层比标准库丰富得多，只是它压根不给开发者直接用std::thread的机会。这篇文章是Unreal对C++做了什么系列的第12章，咱们把工具库里最容易被低估的多线程部分拆开讲讲，重点回答一个核心问题：Unreal到底用自己的线程系统解决了什么，我们该怎么在这套体系里写出安全、高效、不折腾的并发代码。

先说个结论：Unreal不使用std::thread不是因为它做不到，而是因为它认为“线程”这件事不该由开发者直接管理。引擎需要控制线程的数量、优先级、命名、生命周期和调度方式。你需要学会的，是FRunnable、FThread、Async、ParallelFor、FEvent、FCriticalSection这一整套工具箱。下面从设计动机讲到实战排查，逐步展开。

1. 为什么Unreal要对std::thread“动手”

1.1 std::thread在游戏引擎里“水土不服”

从C++11开始，Unreal就支持标准库了，技术上你完全可以在任意代码里写std::thread，编译器不会拦你。但只要你往这个线程里塞一点点引擎相关的东西——访问UObject、调用引擎API、读取某个全局Gameplay状态——系统就会在某个随机时刻用崩溃来回应你。我见过一个从服务端转来做UE的同事，第一天用std::thread写了个资源预加载，加载完想直接设置Actor的属性。运行几分钟后编辑器崩了，日志最后一行是Access violation加一堆无法辨认的地址，内存里全是AAAA或CDCD这样的填充值，典型的野指针写坏堆。后来才发现，这个裸线程访问了UObject的内部属性，而UObject的反射、GC、网络复制系统全部默认只在GameThread工作，多线程一碰就是雷。

这就是最核心的矛盾：std::thread虽然跨平台，但它的能力边界太窄。它只能保证“你创建一个线程，它执行一个函数”，至于线程优先级、线程命名、堆栈大小、处理器亲和性，标准库一概不管。而Unreal作为一个游戏引擎，必须要管这些东西。举个例子，UE在崩溃日志里会把当前线程名字直接打印出来，比如GameThread、RenderThread、AudioThread。你能一眼看出是哪个线程出了问题。如果你自己开一个裸线程，它只会显示为Unknown Thread，排错难度直接翻倍。

另外还有平台差异的问题。Windows上的线程API、Android上的线程API、主机平台上的线程API各不相同。std::thread虽然帮你做了抽象，但它抽象出来的只是“线程能跑”这个基本事实，改优先级、绑定CPU核心、设置线程池容量这些能力要么没有，要么搞得不透。Unreal需要稳定复现这些底层细节，才能保证印度洋对岸的工作室跟你在同一个引擎版本上跑出一样的性能表现。所以官方选择不用std::thread做核心调度，而是自己做一层HAL（硬件抽象层），再把线程封装成FRunnableThread。

换句话说，不是std::thread不能用，而是它在Unreal的语境下不够用。引擎要的是统一管理、可控生命周期、可观测可调试，这些东西裸标准库都给不了。

1.2 Unreal线程系统的设计思路

理解了原因，再看设计就顺了。Unreal的线程系统有一个核心思想：把“线程”弱化，把“任务”强化。你在写并发代码时，不应该想着“我要开一个线程，然后在里面跑一个死循环”，而是应该想着“我要把一个任务丢给引擎，引擎决定它什么时候在哪个线程上跑”。这个思路在Async、ParallelFor、TaskGraph这些工具里体现得很清晰。任务之间可以声明依赖关系，引擎会帮你调度，你不需要关心到底有几个工作线程在跑，更不需要关心它们各自是谁。

线程的生命周期也由引擎统一管理。引擎关停时，会挨个通知所有工作线程退出，等待它们清理完毕，再释放资源。这套机制对应到代码里就是FRunnableThread内部的线程终止流程，所有自有线程都要走一遍“请求停止、等待退出、清理资源”的完整过程。裸std::thread没有这个生命周期约束，你在进程退出时只能硬打断，很可能留下一个线程还在访问已经被销毁的对象。

所以，“Unreal不用std::thread”的真正含义是：Unreal从头实现了一套更贴合游戏引擎的线程调度、线程池、同步、任务派发机制，并且把所有底层细节与自己的内存分配器、统计系统、崩溃上报系统做了深度绑定。你要做的是放弃“线程老子说了算”的念头，接受“引擎帮你管线程”这个设定。

2. 入门必看：FRunnable和FThread这两根顶梁柱

2.1 FRunnable：老派但完整的线程接口

FRunnable是Unreal最原始的线程抽象，对标的就是标准库里的线程函数，但它定义的接口更完整。它包含四个生命周期方法：Init、Run、Stop、Exit。这四个方法合起来定义了一个线程从出生到死亡的完整状态机。

Init在真正进入线程主体前调用，用来做初始化，比如准备线程独有的资源、建立连接等。如果返回false，线程会直接退出，不会进入Run。Run是线程主函数，也就是你的业务逻辑所在，它应该循环处理任务，等待事件，直到外部通知它停止。Stop是通知线程停止的入口，由外部线程调用，你在这里通常只需要设置一个标志位。这里有个关键点：Stop不应该阻塞等待线程退出，它只是“发信号”，真正等待退出要在外部做。Exit在线程退出前调用，用来释放线程内部资源。

看一个最基础的FRunnable实现：

// MyWorker.h #pragma once #include "HAL/Runnable.h" #include "HAL/RunnableThread.h" #include <atomic> class FMyWorker : public FRunnable { public: FMyWorker() : bStop(false) { } virtual bool Init() override { // 启动线程前做初始化 return true; } virtual uint32 Run() override { while (!bStop.load()) { // 处理一批队列数据，或者等待某个事件 // 可以在临界区里处理任务，但不要空转 FPlatformProcess::Sleep(0.01f); } return 0; } virtual void Stop() override { // 通知线程尽快退出 bStop.store(true); } virtual void Exit() override { // 清理线程内部资源 } private: std::atomic<bool> bStop; };

创建线程的代码更简单：

FMyWorker* Worker = new FMyWorker(); FRunnableThread* Thread = FRunnableThread::Create(Worker, TEXT("MyWorkerThread"), 0, TPri_Normal);

注意两个参数：第三个参数是堆栈大小，传0代表使用引擎默认值；第四个是线程优先级，一般用TPri_Normal就够。线程名字一定要起好，崩溃日志、调试器、Profiler里显示的都是它，建议格式是“模块_职责”，比如“AssetLoader_BackgroundIO”，一看到名字就知道它是干什么的。

这里最容易犯的错误是生命周期管理。FRunnableThread::Create不会接管Runnable对象的所有权，线程跑完不会帮你delete这个Worker。正确做法是把它俩都作为类的成员变量，负责线程的类析构时，先调Stop，再等待线程完全退出，最后释放Worker对象。顺序搞反，极容易出现“线程还在跑，Runnable已经挂了”的野指针崩溃。

2.2 FThread：UE5的轻量级新选择

UE5之后，官方觉得FRunnable这套写法还是太重了，于是加了FThread。它的最大特点是直接用lambda作为线程体，不需要单独定义Runnable类。比如：

#include "HAL/Thread.h" FThread MyThread(TEXT("QuickThread"), [this] { // 这里是线程体 float Result = 0.f; for (int32 i = 0; i < 100000; ++i) { Result += FMath::Sqrt(static_cast<float>(i)); } // 计算完成后，通过线程安全方式通知外部，不要直接碰UObject });

FThread内部依然走FRunnableThread那套底层机制，但对外接口简洁到只需要线程名和lambda。购买点是“临时开一个后台线程做点一次性的事”，比如加载一个资源、算一个临时结果，用FThread非常合适。

要注意FThread的析构行为：它会等待线程结束（相当于Join），所以把FThread定义成类的成员变量是安全的。但前提是你能够接受析构时可能阻塞一段时间。如果那个lambda体非常长，析构可能会卡住主线程，这在GameThread上尤其危险。我见过一个案例，一个FThread被Actor成员引用，Actor被销毁时FThread还在跑一个几十秒的大循环，结果关卡切换直接卡死。解决办法是销毁前先给线程发退出信号，或者确保线程体在合理时间内能主动结束。

FThread适合一次性任务。如果你的业务需要长期常驻的后台线程，或者有大量结构化任务要反复调度，还是用FRunnable配上线程池更合适。它俩不是互相替代，而是分工不同。

2.3 线程生命周期：该谁管，怎么管

不管用哪种方式创建线程，你都必须养成“完整走完生命周期”的习惯。线程结束不是一个“Stop一下就行”的动作，而是“请求停止、等待退出、清理资源”三个步骤缺一不可。下面是我在实践中总结出来的标准流程。

• 使用std::atomic 或UE封装的标志位控制线程退出，不要用普通bool，否则多线程下的读写竞争导致的未定义行为就是定时炸弹。
• Stop方法只设置标志位，不做阻塞等待，因为它是被外部线程调用的。
• 在管理线程里等待目标线程退出，通过FThread析构或FRunnableThread的Join方法。
• 线程退出后再释放它可能引用的外部对象。

这条顺序反了，视频里最常见的就是：后台线程正在访问Actor的成员变量，主线程却已经把这个Actor标记为PendingKill并释放了。轻则随机崩溃，重则GC回收后再次访问导致直接崩溃。调试这种Bug特别恶心，因为崩溃点经常不指向真正出错的那行代码，而是指到一段看似无辜的遍历上。

3. 真正每天都在用的：Async、ParallelFor和线程池

直接创建线程的场景其实不会很多，大多数业务诉求是“不想卡住主线程，把这个耗时活儿扔到后台”。这种情况用Async和ParallelFor就够了，它们最大的优点是不用管理线程对象。

3.1 Async/AsyncTask：一次调用开线程

Async函数是Unreal最常用的异步入口，它有两种执行模式：

// 走全局线程池，适合频率不高、任务量不小的工作 Async(EAsyncExecution::ThreadPool, []() { // 耗时计算，比如复杂寻路、网格生成 }); // 每次调用创建独立线程，适合非常独立、不能被池化干批的任务 Async(EAsyncExecution::Thread, []() { // 独立线程任务 });

ThreadPool模式是首选，多个Async任务会共享全局线程池里的线程，不会出现“并发任务多就多到没边”的失控局面。每次都用EAsyncExecution::Thread模式去开线程，等于放弃所有优化，而且无法复用线程创建开销。只有当你的任务确实需要长期独立运行、不能被其他任务打断时才用Thread模式。

还有一个更贴合引擎内部风格的写法是AsyncTask，它按线程名派发：

AsyncTask(ENamedThreads::AnyThread, []() { // 任意后台线程执行 }); AsyncTask(ENamedThreads::GameThread, []() { // 派发到游戏线程，下一帧Tick时才会执行 });

ENamedThreads是Unreal内部对线程的命名枚举。AsyncTask(ENamedThreads::GameThread)提供了一种把任务拍回主线程的简单方式，但它不是立即执行的，而是排队到下一帧。这里有一个很容易踩的坑：如果谁在后台线程里调用AsyncTask(ENamedThreads::GameThread)后，又同步等结果，等来的就是死锁——任务还没执行，线程先等死了。所以在派回GameThread的任务里，不要期待立即返回值，把所有后续逻辑都丢进那个lambda内部。

Async函数可以返回TFuture，对标std::future，但它更会配合引擎的异步模型：

TFuture<int32> Future = Async(EAsyncExecution::ThreadPool, []() { int32 Sum = 0; for (int32 i = 0; i < 1000; ++i) { Sum += i; } return Sum; }); // 某次时机可以调用Get，阻塞等待结果 int32 Result = Future.Get();

提醒一句：Future.Get()会阻塞当前线程。如果在GameThread上调用，你的游戏帧率会直接变零。正确姿势是不要等待，把后续操作写到异步任务里的lambda末尾，或者存到线程安全容器，让GameThread下一帧再去取。

3.2 ParallelFor：把循环打散交给多核

ParallelFor是优化耗时循环的利器，它会自动把一个for循环拆成多段，分别交给线程池的不同线程执行。代码写法也很直观：

const int32 NumElements = 100000; TArray<float> Results; Results.SetNum(NumElements); ParallelFor(NumElements, [&Results](int32 Index) { Results[Index] = FMath::Pow(FMath::Sin(Index * 0.01f), 2.f); });

这个循环里每个Index只写自己的Results[Index]，没有共享数据依赖，所以天然并行安全。但ParallelFor有几个非常容易踩的坑，写的时候必须带着意识去避免。

• 迭代体里不要访问UObject。哪怕只是读取Actor的位置，也可能撞上GameThread正在销毁这个对象。目录项目里最常见的ParallelFor崩溃就是“在迭代体里访问了某个Actor的Transform，然后这个Actor刚好被关卡流送清掉”。
• 迭代体里不要做阻塞操作。等待锁、读文件、请求网络都不合适。阻塞会让本应并行的迭代变成串行排队，甚至锁竞争比单线程还慢。
• 迭代粒度要够大。如果每个迭代只有几十个指令周期，并行调度开销会吃掉全部收益。经验值是每个迭代至少要有几千甚至上万周期的计算量，才值得走并行。
• 不要故意在迭代体里共享状态并期望原子性。比如在ParallelFor里做Sum += Value，这不是线程安全的，除非你用std::atomic 。

ParallelFor默认是同步的，返回时循环已经全部执行完。UE5还提供ParallelForAsync，返回TFuture，适合“主线程先干别的，循环在后台并行跑”的场景。这种模式在处理“一批资源的轻量预处理”时特别好用，但别忘记，主线程最终还是要拿结果，你需要处理同步点。

3.3 线程池背后的机制

前面反复提的全局线程池GThreadPool，是Unreal默认处理EAsyncExecution::ThreadPool任务的核心设施。引擎启动时，会按照CPU核数创建一批固定数量的工作线程，任务来了就排队执行，任务少了就空闲。这个池子不会因为异步任务多就无限增加线程，所以“并发任务特别多”不会直接影响CPU负载失控。

UE5里TaskGraph系统进一步改进了调度，引进了Work Stealing机制：一个线程处理完自己队列里的任务后，会去其他线程队列里“偷”任务来执行，减少尾部等待。这个思路跟TBB这类并行库类似，但对开发者来说完全透明，你只需要提交任务就行。

从性能优化角度，我强烈建议少去自己new线程。线程创建本身是有开销的，成本相当于一次不小的I/O操作，频繁创建销毁会让性能大打折扣。真正需要长时间常驻、且跟游戏主流程解耦的任务，才考虑专用线程。否则，ThreadPool和Async这套链路已经做了大量优化。

4. 锁、原子量和事件：Unreal的同步原语到底该怎么选

多线程写多了，必然面对锁和同步。Unreal没有直接使用std::mutex，而是封装了自己的同步原语，逻辑上与标准库同构，但风格和命名更游戏化。这一节把常见的选型讲透，让你在写代码时知道该拿哪把钥匙开哪把锁。

4.1 加锁三板斧：FCriticalSection、FRWLock、FSpinLock

FCriticalSection就是互斥锁，对应std::mutex，用于保护临界区。日常开发里的推荐写法是配上FScopeLock使用：

FCriticalSection Section; { FScopeLock Lock(&Section); // 临界区代码，尽量短小精悍 }

FScopeLock是RAII锁，作用域结束自动释放，不管中间有没有return或异常，都能保证解锁。这是默认首选方案，凡是能用FScopeLock的地方就不要手写Lock和Unlock。手动锁的经典问题是：某个if分支里忘了Unlock，然后整个线程卡死，其他线程也在后面排队等这把锁，画面一度非常酸爽。

FRWLock是读写锁，适合“读多写少”的场景。想象一份共享配置表，很多后台线程都在读，但只有极少数线程偶尔改它。用FRWLock能让多个读者同时读，互不阻塞，只有写者进入时才独占。这类锁的关键问题是：不要让持有读锁的线程去尝试升级成写锁，一旦两个线程互相等对方释放，就是死锁。

FSpinLock是自旋锁，只在临界区只有几条指令、持有时间极短时值得用。它不切换线程，而是原地空转等待，省去了万级的上下文切换成本，代价是CPU空转。如果你的临界区里有一点点复杂逻辑，自旋锁的效率会断崖式下滑，因为持有锁的线程虽然只花了一丁点时间，其他线程都在空转燃烧核心。新手建议老老实实用FCriticalSection，性能分析器明确告诉你瓶颈在锁竞争时，再考虑换自旋锁。

下表是锁选型的快速对照：

4.2 原子操作：从TAtomic到std::atomic

UE早期提供过TAtomic模板，但官方现在的建议是直接用std::atomic。这个转变让写惯标准C++的人很舒服，因为语义完全一样。实际项目里最常用的是std::atomic 和std::atomic ，用来做停止标志、计数器、引用计数等轻量同步。

我在FRunnable示例里用的bStop就是std::atomic 。原子操作比锁更快，尤其适合“一个线程写、多个线程读”的简单状态同步。但需要理解：std::atomic只保证单次变量操作原子性，不保证多个变量之间的协同一致性。举个例子，你有两个atomic变量，属性x和y，一个线程先写x再写y，另一个线程读y再读x，如果只是普通原子操作，可能读到的是“y是新的，x还是旧的”这种中间态。这种场景需要更强的内存顺序语义，比如把写操作定义为seq_cst或者用发布-获取模式，必要时配合锁。

UE底层还有FPlatformAtomics，它封装了Interlocked系列函数，非常底层。日常开发基本用不到，但你在Profiler里看到AtomicInc、AtomicAdd之类的名称时，知道它是Unreal原子操作底层的实现，排错会更有方向感。

4.3 FEvent和FSemaphore：线程间的信号灯

锁解决的是“同时访问”问题，但很多业务是“一个线程等另一个线程完成某件事”。轮询等待非常消耗CPU，用事件通知更优雅。Unreal的FEvent对应std::condition_variable的简单用法：

FEvent* Event = FPlatformProcess::GetSynchEventFromPool(); // 工作线程里等待 Event->Wait(); // 阻塞直到被Trigger // 通知线程里唤醒 Event->Trigger();

注意几点。FEvent是从全局事件池里借出来的，用完要调用FPlatformProcess::ReturnSynchEventToPool(Event)还回去，否则会泄漏。Wait支持带超时时间的重载，建议在工作循环里用带超时的Wait，这样线程还能定期检查退出标志，不会无限期等一个永远不来的Trigger。

FSemaphore是UE5新增的信号量，用来控制“最多允许N个线程同时进入某个资源”。典型场景是限制同时发起的网络请求数、限制同时进行的地形文件I/O个数。它更接近std::counting_semaphore，比“维护一个Counter + 一把锁”的方案更不容易写错。

5. 线程之间怎么传数据才不出事

锁和原子解决了“执行同步”，但多线程项目的另一半风险出在“数据传递”上。一个线程算完结果，怎么把结果安全交给另一个线程，用的是哪些容器，存的又是什么，这些问题值得单独讲。

5.1 TQueue：单生产单消费还是多生产多消费

Unreal提供了一套线程安全队列，最常用的是TQueue，使用时必须指定它的队列模式：

#include "Containers/Queue.h" // 单生产者单消费者 TQueue<int32, EQueueMode::Spsc> JobQueue; // 多生产者单消费者 TQueue<int32, EQueueMode::Mpsc> SharedQueue;

这两个模式的核心区别是：Spsc是单生产者单消费者，内部无锁，效率极高；Mpsc是多生产者单消费者，内部加锁，允许不同线程同时入队。项目里最常见的模型是“工作线程从池里取任务出队，完成后把结果放入另一个队列，由UI线程消费”，这种一进一出都只有单边写者的模型，用Spsc就非常舒服。

最容易踩的坑是选错模式。如果你有两个线程同时Push，却用了Spsc模式，元素丢失、顺序错乱都还是轻的，严重时直接崩溃。所以写代码前先想清楚队列的消费模型：几个线程入队，几个线程出队。想不清楚就别硬上无锁Spsc，老老实实Mpsc。

TQueue出队时用Dequeue，返回值代表是否成功弹出。弹出后不要再保留元素的引用继续操作队列，这个习惯可以避免很多“脱离队列访问共享内存”的隐蔽问题。

5.2 回到GameThread：跨线程派发UI和UObject操作

UObject、Actor、Component、Widget这些对象有一个铁律：只能在GameThread上访问。这个规则怎么强调都不为过，因为Unreal的反射系统、GC、RHI绑定，都没有给UObject做线程安全。后台线程想更新UI，不能直接访问TextBlock或Image，必须把操作派发回GameThread。

最简单的派发方式是AsyncTask接口：

// 在某个工作线程里 AsyncTask(ENamedThreads::GameThread, [WeakThis = MakeWeakObjectPtr(this), Result]() { if (IsValid(WeakThis.Get())) { UMyWidget* Widget = Cast<UMyWidget>(WeakThis.Get()); if (Widget) { Widget->ResultText->SetText(FText::FromString(FString::FromInt(Result))); } } });

这里的关键点是捕获了一个TWeakObjectPtr，而不是裸指针。后台任务可能延迟几帧才执行，如果在这期间Actor被释放了，WeakObjectPtr会安全地返回nullptr，代码不会访问到野指针。这是跨线程传递UObject引用的“标准答案”，所有认真做过Unreal多线程开发的人都应该养成这个习惯。

另一种方式是用FFunctionGraphTask，它支持更精确的线程派发和依赖控制：

FFunctionGraphTask::CreateAndDispatchWhenReady([WeakThis = MakeWeakObjectPtr(this)]() { if (AActor* Obj = WeakThis.Get()) { Obj->SomeGameThreadFunction(); } }, TStatId(), nullptr, ENamedThreads::GameThread);

这个API的好处是它能在TaskGraph里做依赖排序，如果后续还有其他任务依赖这次派发的结果，可以用Future或依赖任务串联。

5.3 写一个安全的“后台加载+回调主线程”示例

把前面的东西串起来，写一个典型的异步加载模型。这个模型在实际项目里非常常见：后台线程做耗时预处理，处理完把结果安全派发回GameThread，然后更新Actor或UI。

// .h class UMyActor : public AActor { GENERATED_BODY() public: virtual void BeginPlay() override; private: void DoAsyncLoad(); void OnAssetLoaded(const TSoftObjectPtr<UStaticMesh>& InMesh); }; // .cpp void UMyActor::BeginPlay() { Super::BeginPlay(); DoAsyncLoad(); } void UMyActor::DoAsyncLoad() { TSoftObjectPtr<UStaticMesh> TargetMesh = LoadObject<UStaticMesh>(nullptr, TEXT("/Game/Assets/Cube.Cube")); Async(EAsyncExecution::ThreadPool, [ThisWeak = MakeWeakObjectPtr(this), TargetMesh]() { // 模拟耗时操作：解压、计算网格数据、检查引用关系 FPlatformProcess::Sleep(2.0f); AsyncTask(ENamedThreads::GameThread, [ThisWeak, TargetMesh]() { AActor* Self = ThisWeak.Get(); if (!Self || !IsValid(Self)) { return; } UStaticMesh* Mesh = TargetMesh.LoadSynchronous(); if (Mesh) { // 在这里安全地更新Actor组件属性或UI } }); }); }

两层异步的结构很清晰：第一层用EAsyncExecution::ThreadPool做耗时工作，不阻塞GameThread；第二层用AsyncTask派发回GameThread，更新只有在主线程上安全的东西。整个过程中所有跨线程传递的对象引用都被WeakObjectPtr包裹，这是安全性的根本保障。

实际项目里还有更多细节：后台加载失败怎么办，用户已经切换关卡怎么办，多个异步任务并发时完成顺序如何处理。我的做法是给每个异步操作分配一个唯一ID，回调时带上这个ID，再检查当前状态是否允许更新。如果用户已经切到别的关卡，直接丢弃过期结果。

6. 实战排查：多线程Bug的几种典型死法和排查套路

从理论到落地，中间隔着无数Bug。这一节把我在项目里亲眼见过的多线程问题按“死法”分类，写成一张排查速查表。

6.1 崩在UObject：非法跨线程访问

这是多线程问题里出现率最高的一个。表现为后台线程写完某个数据后，GameThread突然在随机位置崩，或者编辑器长时间运行后内存逐渐腐坏。深挖下去，往往是在一个后台线程里直接访问了Actor或Component的属性。

排查思路很直接：崩溃时先看Callstack，如果某个栈帧跟UObject属性读写、反射、GC相关，优先怀疑跨线程。然后在代码里搜索后台线程中直接访问Actor、Component、Widget的地方。工程最稳的验证办法，在目标访问点加一行断言：

check(IsInGameThread());

只要后台线程触碰了这里，断言会立刻弹出来，日志会显示崩溃线程的名字。这样就能快速定位是哪一行代码违反了线程规则。

6.2 锁死：死锁的锅经常不在锁本身

死锁的典型症状是游戏卡在一个画面不动，Profiler显示多个线程都在等锁。排查死锁先看两个地方：锁顺序和锁范围。

锁顺序问题：线程A先拿锁A再拿锁B，线程B先拿锁B再拿锁A，当它们同时执行时就互相等待。解决办法是全局统一锁的顺序，比如约定好所有代码都是“先A后B”。锁范围问题：不要在一个已经持有锁的临界区里再去调用另一个会加锁的函数。我自己犯过这种低级错误，在一个临界区里调用了日志输出，日志函数内部又加了同一把锁，直接当场锁死。

平时写代码多用FScopeLock，这个RAII锁在函数提前返回、异常抛出的情况下都能正确释放。它能从源头堵住“漏解锁”导致的死锁问题。

6.3 性能不升反降：开线程前先算账

很多人一听说ParallelFor好用，就把所有热点循环都替换掉，结果一部分场景性能没有提升反而抖动。原因在于并行是有成本的：线程调度、缓存一致性、锁竞争。如果一个循环只有几千个元素，每个迭代只有几十条指令，并行开销可能比计算本身还多。

我的经验是先测量再并行。用Unreal Insights或CSV Profiler跑一遍数据，确认热点循环确实占了一两毫秒以上，再考虑并行。并行时也不要直接按“元素个数/核数”去分片，可以试验不同任务粒度。一个直观标准：单个任务的串行执行时间达到几十到几百微秒，才值得用线程去分流。低于这个量级，并行只是自我安慰。

6.4 调试多线程：给线程起名、看日志、抓dump

Unreal多线程调试有几个特别实用的手段。第一，所有线程必须起名，FRunnableThread::Create的第二个参数或FThread的第一个参数都可以填名字，用“模块_职责”格式，一看到名字就知道它是干什么的。第二，用日志看线程上下文。UE日志系统会在每行前打印线程名，比如“LogTemp: Warning: [GameThread] ...”，看到前缀就知道它属于哪个线程。第三，崩溃时保存完整minidump，用Visual Studio这类工具加载dump后，在线程窗口能看到每个线程的名字和调用栈，跨线程问题在这个窗口下一目了然。

如果崩溃发生在编辑器环境里，可以额外打开Unreal Insights，它会记录每个线程的调度时间线、锁竞争、任务排队信息。有时候一个看起来没有规律的多线程卡顿，在Insights时间线里就是几个线程互相等待的清晰波浪图。先看线程名，再看调度时间线，最后定位错误代码，这是我在实际项目里用得最多的三部曲。

最后分享一条我自己的习惯：多线程不是“在代码里多写几行”的事，而是“把数据流画清楚”的事。动手写Async、ParallelFor、FThread之前，先用几分钟在白纸上画出谁生产、谁消费、谁可以并行、谁必须串行。画清楚了，代码自然会安全很多。我见过太多项目被多线程Bug折磨，回溯下来，全是最开始没有想清楚“谁拥有数据”就开始动手。Unreal不用std::thread不是限制，反而是帮你把并发开发的思考过程变成了规范。