Lua热更新机制

怎么解决热更的这些问题

场景拆分

    Lua代码的实体可拆分出三类：配置、逻辑和运行时状态，其中逻辑分为常规的接口和闭包内的逻辑，运行时状态又分为全局变量和闭包内的局部变量，这里结合skynet的解决方案进行描述。

热更的核心问题

    1）新老版本的差异是什么？

    2）怎么处理这种差异？

解决方案的核心思路

    1）为了降低热更对原有逻辑的影响，Lua热更总体采取的是原地替换的机制，即用新模块生成的table或者function的组件去替换已有模块的组件；

    2）针对模块内值类型全局变量，以及全局表的值类型字段，对于新老版本只有一个版本有的取并集，新老版本都有的，则新版本的值覆盖老版本的值

    3）针对老模块里面的闭包对象，里面的function要用新版本的对象（即逻辑更新），而upvalue则根据初始态是否为nil标识是否为运行时状态（是nil表示为运行时状态就不覆盖，否则表示常规变量直接覆盖）

    4）若是闭包里面的upvalue出现了新增或者删除，则已新的为准，但是值保留

下面依次拆解源码看这个问题

一些约定

不允许热更模块修改全局变量

    如下图的代码是不允许的：

local M={}
function M:init()
    test_global()
end

function M:local_print()
    print("local function")
end

function M:bar()
    local_print()
    print("bar")
end

test_global="cccc"

return  M

    如图所示，test_global是全局变量，模块内直接设置了全局变量的值；在现网运行过程中，可能全局变量存了一些状态，若是因为重新加载导致状态被重置无疑有着巨大风险，因此这个限制是合理的

所有外部接口必须模块内显式引入再用

    代码如下：

require "module2"
local M={}
M.test = test_global
function M:init()
    test_global()
end

function M:local_print()
    print("local function")
end

function M:bar()
    local_print()
    print("bar")
end

return  M

    如上面代码所示：test_global是我们引入的外部接口，需要显示将这个外部接口引入到table M M.test = test_global中之后，再去使用；这个主要是为了适配Lua的加载器，仅当外部引用的时候，才会去针对不存在的接口去查全局表，才有机会转入到_ENV表的执行阶段。

对于upvalue要区分局部变量还是运行时状态

    Lua提供了一种upvalue的机制，即函数可以使用外部局部变量，并且若是作为闭包对象返回之后，闭包内的逻辑+变量构成了闭包，闭包内的变量是保留的，类似C++静态变量的机制，当实际运行时，需要一种标识哪些局部变量需要重置，哪些需要保留。

构建沙箱环境

    在热更时，为了避免新模块加载对运行时环境的污染，我们得先构建一个沙箱环境，防止新环境的逻辑加载影响溢出，这里通过_require来实现，如下：

local function reload_one(mod_name)
    ... ...
	local mod_ref_dummy, loader = sandbox.require(mod_name)
    ... ...
  
local sandbox = (function()
	... ... 
	local get_dummy_module = (function()
		local dummy_module_mt
		local function get_or_create_obj(key)
			local obj = dummy_module_cache[key]
			if not obj then
				obj = setmetatable({}, dummy_module_mt)
				dummy_module_cache[key] = obj
				dummy_module_cache[obj] = key
			end
			return obj
		end
		return function(name) -- maybe 'name' contains '.'
			return get_or_create_obj( "[" .. name .. "]")
		end
	end)()
	local get_dummy_global = (function()
		local dummy_global_mt
		local function get_or_create_obj(key)
			local obj = dummy_global_cache[key]
			if not obj then
				obj = setmetatable({}, dummy_global_mt)
				dummy_global_cache[key] = obj
				dummy_global_cache[obj] = key
			end
			return obj
		end
		dummy_global_mt = {
			__metatable = "GLOBAL",
			__newindex = error,
			__pairs = error,
			__index = function(self, k)
				assert(string.isvar(k), "global field must be a valid variable name")
				local parent_key = dummy_global_cache[self]
				local key = parent_key .. "." .. k
				return get_or_create_obj(key)
			end,
		}
		return function(name)
			return get_or_create_obj(name)
		end
	end)()


	-- the base lib function never return objects out of sandbox
	local safe_function = {
		require = internal_require, -- sandbox require
		... ...
	}

	local _require = (function()
		local make_sandbox = (function()
			local global_mt = {
				... ...
				__metatable = "SANDBOX",
				__index = function(self, k)
					local v = safe_function[k]
					if v then return v end
					return get_dummy_global(k)
				end
			}
			return function()
				return setmetatable({}, global_mt)
			end
		end)()
		local function find_loader(mod_name)
			for _, searcher in ipairs(package.searchers) do
				local loader, absPath = searcher(mod_name)
				local t = type(loader)
				if t == "function" then
					return loader, absPath
				elseif t == "string" then
					table.insert(msg, loader)
				end
			end
		end
		return function(mod_name) -- load with sandbox
			local loader, absPath = find_loader(mod_name)
			local env, uv = debug.getupvalue(loader, 1)
			if env == "_ENV" then
				debug.setupvalue(loader, 1, make_sandbox()) -- every loaded module has a unique sandbox
			end
			local mod_ref_dummy = loader(mod_name, absPath)
			if env == "_ENV" then
				debug.setupvalue(loader, 1, nil) -- must set to nil, prevent for enum object
			end
			return mod_ref_dummy, loader
		end
	end)()
    ... ...
	return {
		require = _require,
	}
end)()

上述代码分为三个部分：

    （1）第一部分为寻找对应的Lua加载器并为模块生成闭包，在find_loader中：

    ·package.searchers里面存有不同类型模块的加载函数，针对Lua的模块，加载接口为searcher_Lua

    ·searcher_Lua中通过接口findfile在package.path指明的路径里面寻找对应的Lua模块

    ·luaL_loadfilex经过层层调用走到luaY_parser，通过接口luaF_newLclosure为模块创建closure，并在mainfunc里面将_ENV添加到新模块的upvalue列表中

    （2）第二部分构建沙箱环境

    ·如上述代码所示，在reload接口里面，会先用沙箱对需要加载的模块执行沙箱内加载的操作sandbox.require()，这里sandbox.require()最终指向的是sandbox._require()接口

    ·_require接口里面，主逻辑流程通过debug.setupvalue将_ENV替换为make_sandbox制作的沙箱：

        因为从前面讨论可知：在Lua的模块代码中，整个Lua文件可以认为是一个top-level的function，当加载Lua文件的时候，实际是在执行一个匿名函数，只不过函数体是整个文件，那么此时执行匿名函数实际上是创建了一个Lua closure，在Lua与upvalue一文中可以知道，Lua-closure里面有一个upvalue列表，记录了函数内引用的外部局部变量，而若文件内引用了全局变量，这个top-level函数也将其认为是一类upvalue，只不过不是一一存放，而是统一将_ENV作为自己upvalue列表的表项，并放在第一的位置，后续引用全局变量本质上是从upvalue列表取出_ENV并进行访问，因此后面执行的debug.setupvalue(loader, 1, make_sandbox())实际上是替换了_ENV为make_sandbox指向的table（一个以global_mt为metatable的空表）。

    ·而make_sandbox返回的是一个空表，这个表：

        1）global_mt是它的元表，并且实现了__index元方法

        2）所有查询这个空表找不到的对象，会先去找safe_function，找不到则调用方法get_dummy_global，本质上是插入了dummy_global_cache里面建立双向引用

    ·通过上述两步操作，则后续要加载的Lua模块存在外部引用的时候，本地找不到默认都插入到dummy_global_cache里面了

    ·此外有额外需要注意的一些点：

        1）所有的外部引用都被插入到dummy_global_cache表里面

        2）外部引用无论是table、function还是其他，在沙盒内都是一个table对象，且这个table有元表为dummy_global_mt

        3）dummy_global_mt也是实现了__index元方法的元表，当访问外部对象是table类型，且访问其一个entry，则对于entry会被以tab-name.entry_name的格式插入到dummy_global_cache

    （3）第三部分执行模块加载操作

    ·find_loader返回的是新创建的闭包loader和对应文件的路径abspath

除此之外，还有一个internal_require接口需要注意：

    ·internal_require解决的是所加载模块引用了其他模块的情况，即调用require的情形

    ·因为前面_ENV已经被替换了，所以有外部引用的时候，会进入global_mt里面找，这里先找safe_function，里面require被重定位到internal_require

    ·internal_require里面有一个_LOADED_DUMMY记录外部引用的模块key-val pair，若是找不到，通过接口get_dummy_table添加到表dummy_module_cache中

建立新老模块映射关系

    构建好沙箱环境之后，为便于后续原地替换，需要先预处理一下，建立新老模块的映射图，这个是通过match_objects和match_upvalues做到的，在这之前需要先拿到新老模块的key-object的映射关系，如下所示：

local function reload_one(mod_name)
	... ...
	-- all dummy table/function in mod_ref_dummy
	local dummy_path_list, obj_path_list = enum_tbl_func_dummy(mod_ref_dummy)
	-- find all match objects and addition objects
	local newTbl2oldTbl, newFunc2oldFunc = match_objects(obj_path_list, old_real_mod)
	-- according to the match function, find all match upvalues
	local newID2oldUV = match_upvalues(newFunc2oldFunc)
    ... ...
end

这段代码分为三个部分：

    ·通过接口enum_tbl_func_dummy将模块内的对象列表和外部引用列表分离开

    ·通过接口match_objects将模块更新前后的新老对象进行关联

    ·通过接口match_values将模块更新前后的新老upvalue进行关联

    第一部分，通过enum_tbl_func_dummy将模块内的对象和外部引用对象拆分开，如下：

local enum_tbl_func_dummy = (function()
	local function iterate_function(func, depth)
		insert(obj_path_list, {func, table.unpack(path)})
		for idx, name, value in debug.upvalues(func) do
			local t = type(value) -- type of value
			if t == "function" or t == "table" then
				path[depth] = name
				iterate_object(value, t, depth)
				path[depth] = nil
			end
		end
	end
	local function iterate_table(tbl, depth)
		if is_dummy(tbl) then
			insert(dummy_path_list, {tbl, table.unpack(path)})
		else
			insert(obj_path_list, {tbl, table.unpack(path)})
			for key, value in pairs(tbl) do
				local t = type(value) -- type of value
				if t == "function" or t == "table" then
					path[depth] = key
					iterate_object(value, t, depth)
					path[depth] = nil
				end
			end	
		end
	end
	function iterate_object(obj, t, depth)
		if has_traversed[obj] then return end
		has_traversed[obj] = true
		depth = depth + 1
		if t == "function" then
			return iterate_function(obj, depth)
		else -- table
			return iterate_table(obj, depth)
		end
	end
	return function(object)
		local t = type(object)
		if t ~= "function" and t ~= "table" then return end
		iterate_object(object, t, 0)
		local dummy, obj = dummy_path_list, obj_path_list
		return dummy, obj
	end
end)()

    ·mod_ref_dummy是sandbox.require返回的以所加载的文件为函数体的闭包

    ·enum_tbl_func_dummy中，根据对象类型进行处理，发现是function类型，调用接口iterate_function，否则是table类型，调用iterate_table，对于所加载的模块来说，可以是top-level的function，此时下面调用的是iterate_function，并且：

    has_traversed这个table，里面记录了这个闭包里面哪些object已经被遍历，避免无限嵌套

    ·iterate_function中，先把自己添加到obj_path_list这个数组中，然后遍历这个func的upvalue列表

    因为这个文件内定义的function一定是本文件的，所以必然归入到obj_path_list列表中

    ·iterate_table中：

    对于所加载模块，若是存在外部引用，那么外部引用是一个以global_mt或者dummy_module_mt为元表的table，所以在iterate_table中，会先看是不是外部引用is_dummy是的话丢到dummy_path_list，否则丢到obj_path_list

    第二部分，通过match_objects实现新老模块同名对象的关联：

local function reload_one(mod_name)
	... ...
	-- all dummy table/function in mod_ref_dummy
	local dummy_path_list, obj_path_list = enum_tbl_func_dummy(mod_ref_dummy)
	-- find all match objects and addition objects
	local newTbl2oldTbl, newFunc2oldFunc = match_objects(obj_path_list, old_real_mod)
    ... ...
end    

local function match_objects(TF_path_list, old_real_mod)
	for _, TF_path in ipairs(TF_path_list) do
		local newTF = TF_path[1] -- table/function from 'the reload one'
		local ok, old_one = pcall(find_oldTF, old_real_mod, TF_path)
		if not ok then
			type_error(TF_path, "type mismatch: ")
		end
		local t = type(newTF)
		local newTF2oldTF = t == "table" and newTbl2oldTbl or newFunc2oldFunc
		local oldTF = newTF2oldTF[newTF]
		newTF2oldTF[newTF] = old_one
	end
	return newTbl2oldTbl, newFunc2oldFunc -- , additionTF
end

对于match_objects的参数：

    ·old_real_mod，对于使用这个库进行热更的模块，最终模块需要return M这样一个语句，用于require返回一个table，old_real_mod用于接收这个table，里面键值对是模块内定义的function和var及其值

    ·但是对于Lua的require来说，若是这个模块事先已经加载了，则require(mod-name)返回的是已加载的table（即require会先找本地的package.loaded表，有的话就直接返回），所以这里是old_real_mod

    ·TF_path_list接收的是前面obj_path_list的值，obj_path_list是一个列表，记录的是模块内所有定义的function、table等的名字到对象地址的映射关系，其中第一个元素即（obj_path_list[1]存放的是所加载模块的地址（在Lua中，一个模块可以认为是一个表）），如下图：

在match_objects中：

    1）for _, TF_path in ipairs(TF_path_list) do主循环用于遍历更新后模块的每个item，对里面的每个item，通过接口find_oldTF，去old_real_mod里面找到同名对象的地址。

    对于TF_path_list来说，TF_path_list里面除了第一个，TF_path_list[2 - len]每一项是一个数组，含有两个元素，第一个是对象地址，第二项是对象的名字

    2）match_objects做了限制assert(type(newTF)==type(old_one))，即不允许更新后模块类型发生改变。

    例如，更新前，bar是function类型，更新后是integer类型，这种是不允许的

    3）匹配的结果分别丢到newTbl2oldTbl和newFunc2oldFunc里面，建立新函数（表）到老函数（表）addr->addr的映射

    4）find_oldTF处理的node有两种，table类型，直接处理；function类型，则遍历其upvalue逐个进行处理

    第三部分，通过match_upvalues实现新老模块同名upvalue的关联：

local function match_upvalues(newFunc2oldFunc)
	-- find match func's upvalues
	local newID2oldUV = {}
	for newFunc, oldFunc in pairs(newFunc2oldFunc) do
		for idx, name, value in debug.upvalues(newFunc) do
			if name == "" then break end
			local _, old_idx = find_upvalue(oldFunc, name)
			if old_idx then
				local id = debug.upvalueid(newFunc, idx)
				local old_id = debug.upvalueid(oldFunc, old_idx)
				local oldUV = newID2oldUV[id]
				if not oldUV then
					newID2oldUV[id] = {
						old_func = oldFunc,
						old_idx = old_idx,
						old_id = old_id
					}
				else
					assert(old_id == oldUV.old_id, string.format("Ambiguity upvalue: %s .%s", tostring(newFunc), name))
				end
			end
		end
	end
	return newID2oldUV
end

将新老模块里面同名function进行映射之后，match_upvalues解决的是这些同名函数内upvalue的映射问题，这里主体框架如下：

    ·for newFunc, oldFunc in pairs(newFunc2oldFunc)，newFunc2oldFunc里面存放的是新老同名方法的映射对，这里逐个取出进行处理；

    ·for idx, name, value in debug.upvalues(newFunc)，debug.upvalues(newFunc)里面存放的是更新后方法里面upvalue的列表，逐个取出，并根据名字，通过接口find_upvalue在老方法里面去找，找到的话把映射关系存入newID2oldUV里面；

    ·值得注意的是debug.upvalueid里面标识每个upvalueid用的是对应upvalue在内存中的地址，所以这个id是全局唯一的。

迭代更新

    完成同名模块新老版本的映射关系之后，需要在原地将老模块的指令、值等替换成预期要更新的新模块，这属于迭代更新要处理的逻辑范畴，这分为两步，第一步是将函数里面的upvalue进行更新（patch_funcs_upvalue来处理），第二步是将表里面字段进行更新（由patch_tables处理)：

local function reload_one(mod_name)
	... ...
    -- first: make new function join to the old upvalue, and update the upvalue's value
	patch_funcs_upvalue(newID2oldUV, newFunc2oldFunc) -- must before patch table

	-- second: update new table's value to the old table, contains the mod_ref_dummy itself and old_real_mod itself
	patch_tables(newTbl2oldTbl)

	... ...
end

upvalue迭代更新

    func里面upvalue迭代更新走的是接口patch_funcs_upvalue，如下代码列表所示：

local function patch_funcs_upvalue(newID2oldUV, newFunc2oldFunc)
	for newFunc in pairs(newFunc2oldFunc) do
		for idx, name, value in debug.upvalues(newFunc) do
			if name == "" then break end
			local id = debug.upvalueid(newFunc, idx)
			local oldUV = newID2oldUV[id]
			if oldUV then
				debug.upvaluejoin(newFunc, idx, oldUV.old_func, oldUV.old_idx)
				if value ~= nil and type(value) ~= "table" then
					debug.setupvalue(newFunc, idx, value)
				end
			end
		end
	end
end

对于这个接口，我们这么理解：

    ·newFunc2oldFunc是通过match_objects获取的，里面存放的是新老function的映射关系

    ·newID2oldUV是通过match_upvalues获取的，里面存放的是同function新老upvalue的映射关系

    ·patch_funcs_upvalue则通过遍历newFunc的upvalue，逐个去newID2oldUV里面找，通过接口debug.upvaluejoin关联起来

    ·match_objects实际上把模块内的对象都找出来放在表里面了，包括闭包对象，而闭包对象本身一旦创建后就是一块独立的内存，其变量和逻辑不因模块发生更新而变更，这意味着对于相同function返回的闭包，内存中可能因模块更新存在两套代码和变量，而patch_funcs_upvalue的目的就是将这两套闭包模型的upvalue指向同一块内存

upvalue分为四种情况：

    1）新模块有老模块没有的upvalue，直接加入即可

    2）新模块没有老模块有的upvalue，不用管，自然废弃

    3）新老模块都有，存放的是运行时状态的upvalue，在这里以初始值是否为nil进行区分，针对此类upvalue不能动，需要保留其运行时状态

    4）新老模块都有，存放的是临时状态的upvalue，重置其初始值

如下图所示：