【性能调优】GC 压力清单：常见 LuA 写法的分配热点

实战应用：用在哪里

GC 的停顿只是症状，病根是代码里的分配热点：每帧创建的临时表、循环里的字符串拼接、事件回调的闭包重建——分配得越多回收越勤。GC 压力清单把常见的分配反模式列成检查表，按图索骥地减量。

热点的清单

---反模式一：循环内创建临时表
-- 危险：每帧新建 60 个表
function Bad.update(dt)
    local pos = { x = actor.x, y = actor.y }   -- 每帧分配
    Grid.insert(pos)
end

-- 改造：复用表，写前清空
local pos = {}
function Good.update(dt)
    pos.x = actor.x
    pos.y = actor.y
    Grid.insert(pos)
end

---反模式二：循环内的字符串拼接
for _, row in ipairs(rows) do
    log = log .. row.name .. ","     -- 每次创建新串
end
-- 改造：concat 收集后一次成型

清单的前两名：循环内的临时表分配与字符串累加。临时表的改造是提升作用域加复用清空；字符串的改造是 table.concat 一次成型。两者在每秒千次的热路径上，单点的分配放大成每秒数万次，GC 的工作量与分配量成正比——减半分配就是减半回收。

压力的度量

---分配速率的监控：每 10 秒采一次内存增量
setontimerex(79, 10)
function GCMonitor.sample()
    local now = collectgarbage("count")
    local delta = now - (GCMonitor.last or now)
    GCMonitor.last = now
    GCMonitor.series[#GCMonitor.series + 1] = delta
    -- 内存锯齿的振幅持续放大即分配热点回归
    if delta > 200 then
        Ops.alert("10 秒内存增量异常: " ..
            string.format("%.0fKB", delta))
    end
end

压力的度量看内存锯齿：定时采样 collectgarbage("count") 的增量，锯齿的振幅就是每 10 秒的净分配量。振幅的基线随版本归档，新版本让振幅抬升 30% 即分配回归，回归的定位靠火焰图与清单逐项排查。清单的六项：循环临时表、字符串累加、闭包逐帧创建、变参打包、元表元方法滥用、unpack 长数组——每项的改造手法固定，排查的时间从半天缩到按表核对。优化的纪律依旧是先测后改：分配的热点靠数据定位，清单只是候选名单不是必改名单。

验证与监控

改造前后的锯齿对比必须同场景同数据，振幅下降不足两成的改造不合并；GC 的停顿分位与分配速率联动看板，因果两条曲线同屏。

踩坑记录

复用表曾经忘了清空旧键，上一次的数据泄漏进本次逻辑，复用的清空模板化。一处为了优化把局部缓存提到文件级，结果跨模块的状态污染，优化的边界以模块内为限。锯齿监控曾经在 GC 后采样，读数恒低误判无事，采样的时机固定在周期点。

上线要点

清单进代码评审的检查表，热路径新代码逐项过一遍。分配速率的基线随版本归档，回归的判定有历史对照。优化案例库随清单维护，每个反模式配一个真实的改造前后数据。

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