Lua+collectgarbage：GC的手动触发与分步本质

【语法算法】

collectgarbage 的分步回收就这一行：

collectgarbage("step", 200)

"step" 模式让 GC 执行一步增量回收——参数 200 是步长——分步回收的全部机制就这一行。可这一行的前后各有一个场景：前面是"内存持续增长但不想让 GC 一次性停顿太久"，后面是"分步回收的总工作量等于全量回收"。今天拆开。

一、全量、分步、自动三段

collectgarbage 的三段。全量：collectgarbage("collect") 执行一次完整的 GC 循环——标记、清理、清扫三阶段一次性完成——耗时不可控，大堆可能停顿几十毫秒。分步：collectgarbage("step", size) 执行一步增量 GC——每次只做一小部分工作——多次调用分步 GC 的总工作量等于一次全量 GC——停顿被分散到多次调用中。自动：Lua 的 GC 默认自动运行——内存分配达到阈值自动触发——setpause 和 setstepmul 可以调自动触发的阈值和步进速度。三段连起来：collectgarbage 玩的是"GC 停顿的可控化"——全量 GC 是一次性大停顿，分步 GC 是多次小停顿——游戏开发中分步 GC 优于全量 GC。

graph TD
    A["collectgarbage模式"] --> B["collect: 全量回收"]
    A --> C["step: 增量回收"]
    A --> D["count: 查询内存"]
    C --> E["参数size控制步长"]
    C --> F["多次step = 一次collect"]
    B --> G["一次性大停顿"]

二、分步回收的正确写法

-- 每帧执行一步分步GC
local function onFrameGC()
    local stepSize = 200
    collectgarbage("step", stepSize)
end

-- 场景切换时执行全量GC
local function onSceneChange()
    collectgarbage("collect")
    collectgarbage("collect")   -- 两次确保彻底
end

-- 查询当前内存
local function getMemoryKB()
    return collectgarbage("count")
end

SL:RegFrameCallback(onFrameGC)
SL:On("scene_change", onSceneChange)

return { getMemoryKB = getMemoryKB }

collectgarbage("count") 返回当前 Lua 使用的内存量（KB）——监控内存趋势比监控单次值更有意义——内存持续增长说明有引用泄漏。

三、步长的选择与内存的监控

步长 200 是分步回收的默认建议值：步长太小 GC 进度太慢内存持续增长，步长太大单次停顿太长影响帧率——200 是"单步停顿不超过一帧"的经验值。内存监控的意义不在于"看当前值"而在于"看趋势"：每秒采样一次 collectgarbage("count") 画趋势图——趋势平稳说明没有泄漏，趋势持续上升说明有引用泄漏——引用泄漏的根源通常是"全局表持有了不再使用的对象引用"。最后一条纪律：collectgarbage("stop") 可以暂停 GC——暂停后内存持续增长且不会被回收——collectgarbage("restart") 恢复 GC——除非有极其特殊的内存管理需求，否则不要停止 GC——GC 停了就没人帮你回收垃圾了。