【Lua实战】单例模式：全局配置管理器的双重校验

实战应用：用在哪里

掉率、商城、活动三张全局配置被七个模块各自加载，一份配置在内存里存了七份，改表后有的模块新有的模块旧，排查了一整晚。单例配置管理器把加载收敛到一处：实例唯一、懒加载、带防呆的双重校验，改表即全局生效。七份副本的内存浪费还在次要，各模块加载时机不同导致跨模块读到的掉率不一致，才是真正的事故源。

单例实例的双重校验

getInstance 先查实例再查加载标记，实例存在但没加载完时补一次加载，两道校验保证拿到的实例一定可用。

local ConfigMgr = {}
ConfigMgr.__index = ConfigMgr
local instance = nil
function ConfigMgr.getInstance()
    if instance == nil then
        instance = setmetatable({ loaded = false, cache = {} }, ConfigMgr)
    end
    if not instance.loaded then
        instance:load()
    end
    return instance
end
function ConfigMgr:load()
    self.cache.drop = { ["祖玛教主"] = 5000, ["沃玛教主"] = 3000 }
    self.loaded = true
end

业务侧读取与热重载

业务侧通过统一的读取函数取值，未收录的键给缺省值兜底；热重载清空缓存标记重新加载，改表不再需要重启进程。

local cfg = ConfigMgr.getInstance()
local function getDrop(monName)
    return cfg.cache.drop[monName] or 100
end
function ConfigMgr:reload()
    self.loaded = false
    self.cache = {}
    self:load()
    sendcentermsg("配置已热重载，掉率表版本 " .. os.date("%H%M"))
end

验证与监控

单例唯一性验证：五十个模块并发取实例，实例指针逐个比对全部一致；reload 后旧引用读取新数据的时效验证；缺省值兜底覆盖未收录怪物名。监控配置管理器的加载次数与耗时，单次加载超过 200 毫秒要拆分懒加载粒度。

踩坑记录

热更新替换了脚本代码但 instance 变量还指着旧元表的实例，reload 后方法找不到，热更新钩子里要把 instance 置空重建。loaded 标志在加载失败时没有回滚，半份配置被当成完整配置用了一周，加载失败必须把 loaded 保持为假并把错误抛出。单例便利性让它长成了全局垃圾桶，排行榜、邮件草稿都往里塞，注册表按业务域拆分命名空间后才止住。getDrop 的缺省值 100 掩盖过一次配置漏载，缺省命中时打一条告警日志比静默兜底更安全。代码评审随后把绕过 getInstance 直接建表的写法列为禁止项，单例的纪律靠评审守住。双重校验的代价是每次取实例多做一次布尔判断，万次读取的实测开销不足一毫秒，可忽略。