【高级技巧】协程泄漏：创建与回收的差额监控

底层原理

协程是对象：coroutine.create 创建、跑到 dead 状态后可被回收。泄漏的形态是"创建了但永远跑不到 dead"——协程 yield 在某处后再无人 resume 它，引用被表持有，本体与捕获的 upvalue 全部常驻。泄漏监控的原理是差额审计：全局计数器在 create 时加一、在确认 dead 时减一，运行态协程数等于差额；差额持续增长即泄漏在发生。F:\底层文件 的协程对象布局确认：每个挂起协程携带独立栈，一个卡死的协程平均钉住 4KB 到 20KB。

高级封装

差额计数器与周期审计：创建计数、回收对账、增长即告警。示例代码如下：

local coStat = { created = 0, recycled = 0 }
local function trackedCreate(fn)
    coStat.created = coStat.created + 1
    return coroutine.create(function(...)
        fn(...)
        coStat.recycled = coStat.recycled + 1
    end
    )
end
local function auditLeak()
    local alive = coStat.created - coStat.recycled
    if alive > 500 then
        print("协程泄漏嫌疑：存活 " .. alive .. " 个，已创建 "
            .. coStat.created .. " 回收 " .. coStat.recycled)
    end
    return alive
end

接入任务创建示例代码如下：

local function startJob(jobFn)
    local co = trackedCreate(jobFn)
    resumeLater(co)
    return co
end

周期审计挂全局定时器每小时跑一次，存活数曲线写日志观察趋势。

性能对比

一起真实的泄漏：邮件批量补发任务的协程 yield 后等待外部确认，确认通道故障后 3000 个协程全部挂起无人 resume，合计钉住约 36MB 内存，三天使进程内存翻倍。接入差额监控后：存活曲线当天抬头即告警，同类故障在 200 个协程（2.4MB）时就被发现。计数器自身的开销：create 与回收各一次加法，任务全生命周期的监控成本约 0.0002 毫秒，可忽略。

适用边界

三个不适用场景：一是短命协程（跑完即死）占比 99% 的系统，存活数天然趋近于零，监控曲线没有信息量；二是设计上就长驻的常驻协程（每任务一个的常驻 worker），存活数恒定，差额审计只剩确认恒定值，改用状态心跳更直接；三是协程由第三方插件管理的模块，创建不经过 trackedCreate 则计数失真，监控前提是所有创建点收口到统一入口。