【性能调优】协程池：coroutine 对象复用降低 GC 压力

实战应用：用在哪里

频繁创建协程的场景（每帧处理一批寻路请求、每次攻击结算开一个协程）会产生大量 coroutine 对象与闭包，GC 压力随之上升。协程池把执行完毕的协程回收复用，实测高频场景下协程相关 GC 减少 70%。

池化实现

local pool = {}

local function acquire(fn)
    local co = table.remove(pool)
    if co then
        -- 复用：wrap 重新绑定函数体
        return coroutine.wrap(function() fn() end), co
    end
    return coroutine.create(fn)
end

local function run(fn)
    local co = coroutine.create(fn)
    local ok, result = coroutine.resume(co)
    if coroutine.status(co) == "dead" then
        pool[#pool + 1] = co          -- 死协程回收进池
    end
    return ok, result
end

简化版本直接复用"已死的协程壳"意义有限（Lua 没有重置协程的接口），实用的池化是对任务函数闭包与环境表做池化，协程本体每次创建但闭包与数据表复用——GC 大头在闭包与数据表上。

何时值得池化

判断标准三条：协程创建频率（每秒超过 50 个才考虑）、单协程携带的数据量（闭包捕获的大 table 才是大头）、GC 停顿是否可观测（collectgarbage("count") 曲线锯齿）。三项都不满足时，直接创建就是最好的写法——过度池化会让代码难读且引入复用状态串场的隐患。

实测参考

某寻路批量结算场景（每秒 80 个协程、每个携带 200 槽结果表）：池化表复用后，GC 触发间隔从 11 秒拉长到 47 秒，帧最大停顿从 3.1ms 降到 0.9ms。收益确认后把池容量做成配置（缺省 32），峰值超出时退回直接创建，容量与稳定性都可控。

与分帧调度的配合：批量协程任务挂进统一心跳调度器，每帧 resume 一批协程直到帧预算耗尽，剩余协程下一帧继续。协程池的容量按峰值并发设置（缺省 32），池空时退回直接创建并在日志计数，容量配置调整的依据就是这个计数的曲线。

池容量写进配置文件，峰值超出池容量时自动退回直接创建并把次数计入告警计数，容量调整跟着曲线走。

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