【性能调优】Lua GC 机制与内存优化实战

内存是怎么被吃掉的

Lua 里你几乎从不手动申请内存：新建 table、拼接字符串、创建闭包，全都由虚拟机统一分配，再交给垃圾回收器（GC）定期清扫。996 引擎单区动辄几百个玩家对象、成千上万张表，一旦某段代码在循环里疯狂造临时 table 或字符串，GC 压力会瞬间拉高，表现为卡顿集中爆发、帧率锯齿明显。

想确认问题，先学会看当前占用：collectgarbage("count") 返回 Lua 侧内存总量（KB 为单位，返回的是千字节）。在 M2 里用 release_print(collectgarbage("count")) 定点打印，对比功能开启前后的差值，就能判断某个模块是不是内存大户。

local before = collectgarbage("count")
-- ... 执行一段可疑逻辑 ...
local after = collectgarbage("count")
release_print("mem delta KB:", after - before)

常见的三个泄漏点

第一，全局表污染。 未加 local 的变量全部落在 _G 上，GC 永远不会回收它们。批量刷怪逻辑里一个手误的全局计数器，就会把整只怪物对象钉死在内存里。规范做法：模块内一律 local，需要暴露的只挂一个命名空间表。

第二，缓存只进不出。 用 table 当缓存很方便，但要有淘汰策略：容量上限 + 最旧剔除，或定期 缓存表 = {} 整体重置。纯增长缓存是长挂机服最常见的慢性泄漏。

第三，互相引用成环。 A.b = B、B.a = A 的结构，配合元表被别处引用时，很可能整环都无法回收。设计上尽量单向引用，必须成环时在销毁逻辑里手动断链：A.b = nil。

实用优化手法

循环里拼字符串是经典性能坑：s = s .. item 每次都会生成新字符串，O(n²) 复杂度。改成收集到 table 后一次性连接：

local buf = {}
for i = 1, 1000 do
    buf[#buf + 1] = "条目" .. i
end
local s = table.concat(buf, ",")

同理，高频触发的函数里不要每次新建 table 当临时数组，可以在脚本顶层建一个"工作表"反复复用，用完 工作表 = {} 或记录长度后置空。字符串 key 换成数字 key（把配置 id 提前映射成下标）也能明显降低哈希开销。

最后是主动回收时机：在大规模刷怪、活动开关这类天然低谷点，调用一次 collectgarbage("collect") 做全量回收，比让 GC 在战斗高峰期被动触发更稳。把它挂在你可控的业务节点上，而不是定时器里无脑刷。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。