第25章多线程在游戏引擎中的应用

课程目录第25章多线程在游戏引擎中的应用

多线程在游戏引擎中的应用

游戏引擎，说白了就是一套让游戏跑起来的框架。我做了这么多年系统编程，最深的体会就是：游戏引擎对性能的渴求，几乎是无止境的。而多线程，就是满足这种渴求的关键手段之一。

今天咱们聊聊游戏引擎里多线程的几个核心场景。嗯，这些场景我几乎都在实际项目中踩过坑，有些教训至今记忆犹新。

游戏循环与线程

先说说最基础的游戏循环。传统的游戏循环长什么样？

while (gameIsRunning) {
    processInput();   // 处理输入
    update();         // 更新逻辑
    render();         // 渲染画面
}

这个循环跑在单线程里，简单直接。但问题来了——如果 update() 里有个复杂的物理计算，卡了 50 毫秒，那 render() 就得等着。画面就会卡顿。

我早期做一个小型 2D 游戏时，就吃过这个亏。当时角色碰撞检测写得粗糙，一遇到复杂场景，帧率直接掉到 20 以下。后来我把输入处理和逻辑更新拆到不同线程，才缓过来。

一个常见的改进方案是这样的：

// 逻辑线程
void* logicThread(void* arg) {
    while (gameIsRunning) {
        processInput();
        update();
        // 通知渲染线程可以取数据了
        signalRender();
    }
    return NULL;
}

// 渲染线程
void* renderThread(void* arg) {
    while (gameIsRunning) {
        waitForLogic();  // 等待逻辑线程完成
        render();
    }
    return NULL;
}

这样逻辑和渲染就能并行跑了。但要注意，这里有个同步点——渲染线程必须等逻辑线程算完才能开始画。如果逻辑线程跑得慢，渲染线程还是得等。

我的建议： 不要让渲染线程干等。可以引入双缓冲机制——逻辑线程写后备缓冲区，渲染线程读当前缓冲区。这样两个线程几乎可以完全并行。

渲染线程与逻辑线程分离

刚才的例子其实已经涉及了线程分离。但真正的游戏引擎里，分离得更彻底。

逻辑线程管什么？管游戏状态、AI、物理、网络。渲染线程管什么？管顶点数据、纹理上传、绘制调用。

为什么要分离？说白了，两个原因：

帧率不同步：逻辑更新可能只需要 60Hz，但渲染可以跑到 120Hz 甚至更高。绑在一起就浪费了渲染能力。
延迟隐藏：逻辑线程卡一下，渲染线程还能用上一帧的数据继续画。用户感觉不到卡顿。

我记得有一次优化一个手游引擎，逻辑线程里有个寻路算法写得特别重，每帧要算 30 毫秒。如果按单线程跑，帧率只有 33 左右。把渲染分离出去后，渲染线程稳定在 60 帧，逻辑线程哪怕偶尔超时，画面也不抖。

  关键点： 两个线程之间通过共享数据交换信息。这个共享数据必须加锁，或者用无锁队列。我见过太多因为不加锁导致画面撕裂、角色瞬移的 bug。

这里有个典型的数据结构：

typedef struct {
    float position[3];
    float rotation[4];
    int   animationState;
} GameObjectState;

// 共享缓冲区
GameObjectState sharedState[MAX_OBJECTS];
pthread_mutex_t stateMutex = PTHREAD_MUTEX_INITIALIZER;

// 逻辑线程写入
void logicUpdate() {
    pthread_mutex_lock(&stateMutex);
    for (int i = 0; i < numObjects; i++) {
        updateObject(&sharedState[i]);
    }
    pthread_mutex_unlock(&stateMutex);
}

// 渲染线程读取
void renderFrame() {
    pthread_mutex_lock(&stateMutex);
    for (int i = 0; i < numObjects; i++) {
        drawObject(&sharedState[i]);
    }
    pthread_mutex_unlock(&stateMutex);
}

嗯，这里要注意——锁的粒度。如果锁住整个数组，两个线程的并行度就大打折扣。我一般建议按对象粒度加锁，或者用读写锁（读多写少的情况）。

物理引擎并行化

物理引擎是游戏里最吃计算量的模块之一。碰撞检测、刚体求解、约束求解……每一步都可能成为瓶颈。

物理引擎并行化，我总结下来有几种思路：

空间分区并行：把游戏世界分成多个区域，每个区域交给一个线程处理。比如四叉树、八叉树分区。
任务池并行：把物理计算拆成一个个小任务，丢到线程池里执行。每个任务处理一对物体的碰撞检测。
流水线并行：把物理计算分成多个阶段（宽阶段碰撞检测、窄阶段碰撞检测、约束求解），每个阶段一个线程。

我个人比较喜欢任务池的方式。为什么呢？因为游戏场景的复杂度是动态的——有时候角色多，有时候少。任务池能自动负载均衡，不会出现某个线程忙死、其他线程闲死的情况。

来看一个简单的任务池示例：

typedef struct {
    int bodyA;
    int bodyB;
} CollisionTask;

void* workerThread(void* arg) {
    ThreadPool* pool = (ThreadPool*)arg;
    while (1) {
        CollisionTask task = pool->getTask();
        if (task.bodyA == -1) break;  // 终止信号
        detectCollision(task.bodyA, task.bodyB);
    }
    return NULL;
}

// 主线程分发任务
void dispatchCollisionTasks() {
    for (int i = 0; i < numBodies; i++) {
        for (int j = i + 1; j < numBodies; j++) {
            if (broadPhaseTest(i, j)) {
                pool->addTask((CollisionTask){i, j});
            }
        }
    }
}

这里有个坑——broadPhaseTest 本身也要快。我曾经在一个项目里，宽阶段检测写得过于精细，结果比窄阶段还慢。后来改成简单的 AABB 包围盒检测，速度提升了 3 倍。

避坑指南： 我曾经在物理引擎里直接用全局锁保护所有刚体数据，结果 8 个线程跑出了单线程的效果。后来改成每个刚体独立加锁，性能才上来。记住：锁的粒度越小，并行度越高。

还有一个常见问题：物理引擎的确定性。多线程下，任务执行顺序不确定，可能导致物理模拟结果不一致。比如两个物体碰撞的顺序不同，最终位置就不同。这个问题在单机游戏里还好，但在网络同步的游戏里就是灾难。

我的做法是：在物理计算开始前，先对所有任务按某种规则排序（比如按物体 ID），然后按顺序分发到线程池。这样虽然损失了一点并行度，但保证了确定性。

整体架构图

下面这张图展示了游戏引擎中多线程的核心架构。我画得比较简洁，但关键点都在里面了。

从图里能看出来，主线程负责调度，逻辑线程和渲染线程各自干自己的活，物理线程池处理最重的计算。所有线程通过共享数据区交换信息。这个架构我用了很多年，稳定性和性能都不错。

总结一下

游戏引擎里的多线程，核心就三件事：

游戏循环拆开：别让所有事情挤在一个循环里。输入、逻辑、渲染，能拆就拆。
渲染和逻辑分离：两个线程各管各的，通过共享数据同步。注意锁的粒度。
物理引擎并行化：用任务池或者空间分区，把碰撞检测和约束求解分散到多个核上。

嗯，这些说起来简单，做起来全是细节。我当年第一次做游戏引擎多线程优化时，光调试死锁就花了两周。但一旦跑顺了，那种流畅感——值了。

📚 课程目录

多线程在游戏引擎中的应用

游戏循环与线程

渲染线程与逻辑线程分离

物理引擎并行化

整体架构图

总结一下