【性能调优】collectgarbage 的分步调用：停顿的可控化

实战应用：用在哪里

Lua 的全量 GC 一次回收几十万对象时，停顿能到几十毫秒——千人攻城的战斗帧里插一次全量回收，那一帧就卡成幻灯片。分步调用让回收的停顿切成小块摊到空闲期，停顿从不可控变成可预算。

停顿的实测

---全量回收与分步回收的停顿对比
local function fullGC()
    local t0 = os.clock()
    collectgarbage("collect")
    print(string.format("full: %.1f ms", (os.clock() - t0) * 1000))
end

---分步：每步预算 2 毫秒
function GC.step(budgetMs)
    local t0 = os.clock()
    while os.clock() - t0 < budgetMs / 1000 do
        if collectgarbage("step") then
            return true    -- 一轮回收完成
        end
    end
    return false
end

全量 collect 在对象峰值时实测 45 毫秒的停顿，战斗帧的预算只有 33 毫秒——一次全量回收就是一个必然的卡顿帧。collectgarbage("step") 把回收工作切成增量的小步，每步返回是否完成整轮，外层按毫秒预算循环调用：预算 2 毫秒就跑 2 毫秒，跑不完下个空闲期接着跑。停顿的形状从一根尖刺变成平稳的底噪，玩家的帧率曲线不再出现周期性的深谷。

调度的编排

---空闲期驱动的分步回收
setontimerex(66, 5)
function GC.idle()
    -- 战斗高峰时段只做小步，闲时多跑几步
    local busy = Online.peak() > 800
    local budget = busy and 1 or 4
    GC.step(budget)
end

分步的调度按负载自适应：千人在线的战斗高峰每 5 秒跑 1 毫秒的小步，凌晨的低谷放宽到 4 毫秒快跑。内存的水位是另一路触发器：总量超过阈值时不受预算约束连跑几步，内存的失控比一次长停顿更危险，两路触发取或。回收的指标进监控：每步的耗时分布与内存的锯齿曲线，锯齿的振幅收敛说明分步在工作。回收之外的根本解是少造垃圾：对象池复用与字符串常量化让每轮回收的活变少，分步只是让必要的活不碍事。

验证与监控

帧耗时的分位监控：分步上线后 P99.9 的长尾帧应当消失；内存的锯齿振幅周报，振幅异常放大提示分配热点回归。

踩坑记录

分步曾经没有预算上限，单步在对象巨量时自己跑成全量，预算的墙式检查补上。内存水位触发曾经与分步预算打架，水位高时还按小步龟速回收，紧急通道的优先级压过预算。collectgarbage("count") 的读数曾经当真实内存用，它不含 Fragmentation，监控的口径与系统侧对齐后才不再误判。

上线要点

GC 的预算与水位阈值进配置，场景切换（开服、攻城）可动态调整。分步与对象池的组合拳作为战斗服务器的标准配置交付。GC 的停顿数据进版本发布的性能基线，引擎升级前后对比留档。

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