游戏卡顿白皮书 › L9 服务器游戏进程

死循环/逻辑失控 Infinite loop / runaway logic

原因 ID sp-infinite-loop · 主责 研发团队·服务器开发

在含图示和实验的完整版中打开此卡片 →

bug 导致一个 tick 无法结束时，服务器会停住，然后被看门狗强制重启。

起因 条件写错导致循环不结束，或递归失控 → 结果 tick 结束不了，服务器停住 → 画面表现 卡住后所有人掉线

症状

卡住, 掉线

因素

停顿

谁会遇到

特定地点/分线, 全服

何时出现

做特定操作时, 偶尔随机

负责方

主责 研发团队·服务器开发

研发团队要做的事

循环次数上限；看门狗；问题输入的复现测试。

监控图上

连接成批断开 · 连接数、各线程 CPU

查看位置

停住期间用 pidstat -t 1 看各线程的 CPU，用 perf top -t（线程 ID）或 gdb 确认以 100% 运行的线程在哪个函数里打转。已经重启的话，看看门狗超时记录（systemd 的 WatchdogSec、Kubernetes 存活探针失败）

确认依据

服务器停住期间，一个游戏线程一直以 100% CPU 运行，调用栈始终在同一个函数、循环里打转

排除依据

停住期间 CPU 接近 0，看死锁或等待外部响应

确认手段

运维工具即可确认（无需游戏代码）

出处

1. systemd.service(5) — Linux manual page systemd
   WatchdogSec=：服务在规定时间内没发出存活信号（WATCHDOG=1）就视为失败并终止，根据 Restart= 设置自动重启
2. Liveness, Readiness, and Startup Probes Kubernetes
   用存活探针捕捉运行中却无法推进的状态并重启；默认每 10 秒检查一次，连续失败 3 次就重启
3. pidstat(1) — Linux manual page sysstat
   -t 同时显示进程下各线程的统计（CPU 使用率等）
4. perf-top(1) — Linux manual page perf
   按函数（符号）实时显示运行中线程（-t）或进程（-p）的 CPU 使用占比

相关原因

同一层：L9 服务器游戏进程

• Tick 超出预算
• 视野（AOI）计算激增（N²）
• 广播激增
• 单线程区域过载（热点）
• 锁竞争
• 死锁
• 游戏线程中的同步调用
• 消息队列积压
• 定时器集中触发
• 寻路计算激增
• 序列化/压缩开销
• 服务器崩溃
• 线程池耗尽
• 战斗集中在单一目标（世界 BOSS）
• 进入密集区域时实体生成激增
• 实体堆积（未清理的物品/召唤物）
• 版本更新导致流量特征变化

其他层中同样导致“卡住”的原因

• 帧耗时尖峰 L1 客户端游戏进程
• 客户端垃圾回收 L1 客户端游戏进程
• 主线程同步加载/Shader 编译 L1 客户端游戏进程
• 存储设备过慢导致资源流式加载滞后 L1 客户端游戏进程
• 游戏安全模块（反作弊）扫描 L1 客户端游戏进程
• Wi-Fi ↔ 4G/5G 切换 L2 客户端操作系统与设备
• 客户端内存不足/swap L2 客户端操作系统与设备
• 显存（VRAM）不足 L2 客户端操作系统与设备

查看含图示和实验的原卡片