Lua_第16 章 Weak 表

Posted 2020-06-21 heyuchang666

Lua_第16 章 Weak 表

       Lua自动进行内存的管理。程序只能创建对象（表，函数等)，而没有执行删除对象 的函数。通过使用垃圾收集技术，Lua 会自动删除那些失效的对象。这可以使你从内存 管理的负担中解脱出来。更重要的，可以让你从那些由此引发的大部分 BUG中解脱出 来，比如指针挂起（dangling   pointers)和内存溢出。

       和其他的不同，Lua 的垃圾收集器不存在循环的问题。在使用循环性的数据结构的 时候，你无须加入特殊的操作;他们会像其他数据一样被收集。当然，有些时候即使更 智能化的收集器也需要你的帮助。没有任何的垃圾收集器可以让你忽略掉内存管理的所 有问题。

       垃圾收集器只能在确认对象失效之后才会进行收集;它是不会知道你对垃圾的定义 的。一个典型的例子就是堆枝:有一个数组和指向枝顶的索引构成。你知道这个数组中 有效的只是在顶端的那一部分，但 Lua不那么认为。如果你通过简单的出枝操作提取一 个数组元素，那么数组对象的其他部分对 Lua来说仍然是有效的。同样的，任何在全局 变量中声明的对象，都不是 Lua 认为的垃圾，即使你的程序中根本没有用到他们。这两 种情况下，你应当自己处理它（你的程序)，为这种对象赋 nil值，防止他们锁住其他的 空闲对象。

      然而，简单的清理你的声明并不总是足够的。有些语句需要你和收集器进行额外的 合作。一个典型的例子发生在当你想在你的程序中对活动的对象（比如文件)进行收集 的时候。那看起来是个简单的任务:你需要做的是在收集器中插入每一个新的对象。然 而，一旦对象被插入了收集器，它就不会再被收集!即使没有其他的指针指向它，收集 器也不会做什么的。Lua 会认为这个引用是为了阻止对象被回收的，除非你告诉 Lua 怎 么做。

        Weak 表是一种用来告诉 Lua 一个引用不应该防止对象被回收的机制。一个 weak引 用是指一个不被 Lua 认为是垃圾的对象的引用。如果一个对象所有的引用指向都是 weak，对象将被收集，而那些 weak 引用将会被删除。Lua 通过 weak tables 来实现 weak 引用:一个 weak tables 是指所有引用都是 weak 的 table。这意味着，如果一个对象只存 在于 weak tables 中，Lua 将会最终将它收集。

        表有 keys 和 values，而这两者都可能包含任何类型的对象。在一般情况下，垃圾收集器并不会收集作为 keys 和 values 属性的对象。也就是说，keys 和 values 都属于强引 用，他们可以防止他们指向的对象被回收。在一个 weak tables 中，keys和 vaules 也可能 是 weak 的。那意味着这里存在三种类型的 weak tables:weak keys 组成的 tables;weak values 组成的 tables;以及纯 weak tables 类型，他们的 keys 和 values 都是 weak 的。与 table 本身的类型无关，当一个 keys 或者 vaule 被收集时，整个的入口（entry)都将从这 个 table 中消失。

      表的 weak 性由他的 metatable的__mode 域来指定的。在这个域存在的时候，必须是 个字符串:如果这个字符串包含小写字母‘k‘，这个 table 中的 keys 就是 weak 的;如果 这个字符串包含小写字母‘v‘，这个 table 中的 vaules 就是 weak的。下面是一个例子， 虽然是人造的，但是可以阐明 weak tables 的基本应用:

a = {}
b = {}
setmetatable(a, b)
b. mode = \"k\"     -- now 'a'has weak keys
 
key = {}             -- createsfirst key
a[key] = 1
 
key = {}             -- createssecond key
a[key] = 2
 
collectgarbage()     --forces a garbagecollection cycle
 
for k, v in pairs(a) do print(v) end
--> 2

       在这个例子中，第二个赋值语句 key={}覆盖了第一个 key 的值。当垃圾收集器工作时，在其他地方没有指向第一个 key 的引用，所以它被收集了，因此相对应的table 中的 入口也同时被移除了。可是，第二个 key，仍然是占用活动的变量key，所以它不会被收集。

       要注意，只有对象才可以从一个 weak table 中被收集。比如数字和布尔值类型的值， 都是不会被收集的。例如，如果我们在 table 中插入了一个数值型的 key(在前面那个例 子中)，它将永远不会被收集器从 table 中移除。当然，如果对应于这个数值型 key 的 vaule 被收集，那么它的整个入口将会从 weaktable 中被移除。

       关于字符串的一些细微差别:从上面的实现来看，尽管字符串是可以被收集的，他 们仍然跟其他可收集对象有所区别。 其他对象，比如 tables 和函数，他们都是显示的被 创建。比如，不管什么时候当 Lua 遇到{}时，它建立了一个新的table。任何时候这个function()。。。end 建立了一个新的函数（实际上是一个闭包)。然而，Lua见到"a".. "b"的时候会创建一个新的字符串?如果系统中己经有一个字符串"ab"的话怎么办? Lua 会重新建立一个新的?编译器可以在程序运行之前创建字符串么?这无关紧要:这 些是实现的细节。因此，从程序员的角度来看，字符串是值而不是对象。所以，就像数 值或布尔值，一个字符串不会从 weak tables 中被移除(除非它所关联的 vaule 被收集)。

16.1 记忆函数

      一个相当普遍的编程技术是用空间来换取时间。你可以通过记忆函数结果来进行优化，当你用同样的参数再次调用函数时，它可以自动返回记忆的结果。

      想像一下一个通用的服务器，接收包含 Lua代码的字符串请求。每当它收到一个请 求，它调用 loadstring 加载字符串，然后调用函数进行处理。然而，loadstring 是一个"巨大"的函数，一些命令在服务器中会频繁地使用。不需要反复调用 loadstring 和后面接着 的 closeconnection()，服务器可以通过使用一个辅助 table 来记忆 loadstring 的结果。在 调用 loadstring 之前，服务器会在这个 table 中寻找这个字符串是否己经有了翻译好的结 果。如果没有找到，那么(而且只是这个情况)服务器会调用 loadstring 并把这次的结果 存入辅助 table。我们可以将这个操作包装为一个函数:

local results = {}
function mem_loadstring (s)
    if results[s] then       -- result available?
       return results[s]    -- reuse it
    else
         local res = loadstring(s)   -- compute newresult 
         results[s] = res   -- save for later reuse
         return res
      end

end

       这个方案的存储消耗可能是巨大的。尽管如此，它仍然可能会导致意料之外的数据 冗余。尽管一些命令一遍遍的重复执行，但有些命令可能只运行一次。渐渐地，这个 table 积累了服务器所有命令被调用处理后的结果;早晚有一天，它会挤爆服务器的内存。一 个 weak table 提供了对于这个问题的简单解决方案。如果这个结果表中有 weak值，每次 的垃圾收集循环都会移除当前时间内所有未被使用的结果(通常是差不多全部):

local results = {}
setmetatable(results, {_mode = \"v\"})   -- make valuesweak
function mem_loadstring (s)
...    -- asbefore

      事实上，因为 table 的索引下标经常是字符串式的，如果愿意，我们可以将 table 全 部置 weak:

setmetatable(results, {_mode = \"kv\"})

       最终结果是完全一样的。 记忆技术在保持一些类型对象的唯一性上同样有用。例如，假如一个系统将通过。tables  表达颜色，通过有一定组合方式的红色，绿色，蓝色。一个自然颜色调色器通过每一次新的请求产生新的颜色:

function createRGB (r, g, b)
return {red = r,green = g,blue = b}
end

       使用记忆技术，我们可以将同样的颜色结果存储在同一个 table 中。为了建立每一种颜色唯一的 key，我们简单的使用一个分隔符连接颜色索引下标:

local results = {}
setmetatable(results, {_mode = \"v\"})   -- make valuesweak
function createRGB (r, g, b)
      local key = r .. \"-\" .. g ..\"-\" .. b 
      if results[key] then return results[key] 
      else
           local newcolor = {red = r,green = g,blue = b} 
           results[key] = newcolor
           return newcolor
    end
end

       一个有趣的后果就是，用户可以使用这个原始的等号运算符比对操作来辨别颜色， 因为两个同时存在的颜色通过同一个的 table 来表达。要注意，同样的颜色可能在不同的时间通过不同的 tales 来表达，因为垃圾收集器一次次的在清理结果 table。然而，只要 给定的颜色正在被使用，它就不会从结果中被移除。所以，任何时候一个颜色在同其他颜色进行比较的时候存活的够久，它的结果镜像也同样存活。

16.2 关联对象属性

       weak tables 的另一个重要的应用就是和对象的属性关联。在一个对象上加入更多的 属性是无时无刻都会发生的: 函数名称，tables 的缺省值，数组的大小，等等。

        当对象是表的时候，我们可以使用一个合适的唯一 key来将属性保存在表中。就像 我们在前面说的那样，一个很简单并且可以防止错误的方法是建立一个新的对象(典型 的比如 table)然后把它当成 key 使用。然而，如果对象不是 table，它就不能自己保存自 身的属性。即使是tables，有些时候我们可能也不想把属性保存在原来的对象中去。例 如，我们可能希望将属性作为私有的，或者我们不想在访问 table中元素的时候受到这个 额外的属性的干扰。在上述这些情况下，我们需要一个替代的方法来将属性和对象联系起来。当然，一个外部的 table 提供了一种理想化的方式来联系属性和对象(tables 有时 被称作联合数组并不偶然)。我们把这个对象当作 key 来使用，他们的属性作为 vaule。 一个外部的 table 可以保存任何类型对象的属性(就像 Lua 允许我们将任何对象看作 key)。此外，保存在一个外部 table 的属性不会妨碍到其他的对象，并且可以像这个table本身一样私有化。

       然而，这个看起来完美的解决方案有一个巨大的缺点:一旦我们在一个table 中将一 个对象使用为 key，我们就将这个对象锁定为永久存在。Lua 不能收集一个正在被当作 key使用的对象。如果我们使用一个普通的 table 来关联函数和名字，那么所有的这些函 数将永远不会被收集。正如你所想的那样，我们可以通过使用 weak table来解决这个问 题。这一次，我们需要 weak keys。一旦没有其他地方的引用，weak keys 并不会阻止任 何的 key 被收集。从另一方面说，这个table 不会存在 weak vaules;否则，活动对象的 属性就可能被收集了。

       Lua 本身使用这种技术来保存数组的大小。像我们下面即将看到的那样，table 库提供了一个函数来设定数组的大小，另一个函数来读取数组的大小。当你设定了一个数组的大小，Lua将这个尺寸保存在一个私有的 weak table，索引就是数组本身，而 value 就 是它的尺寸。

16.3 重述带有默认值的表

      在章节 12.4.3，我们讨论了怎样使用非 nil 的默认值来实现表。我们提到一种特殊的技术并注释说另外两种技术需要使用 weak tables，所以我们推迟在这里介绍他们。现在， 介绍她们的时候了。就像我们说的那样，这两种默认值的技术实际上来源于我们前面提到的两种通用的技术的特殊应用:对象属性和记忆。

       在第一种解决方案中，我们使用 weak table 来将默认 vaules 和每一个 table 相联系:

local defaults = {} 
setmetatable(defaults, {_mode = \"k\"})
local mt = {_index =function (t) return defaults[t] end}
 
 
function setDefault (t, d) 
   defaults[t] = d
   setmetatable(t, mt)
end
 

      如果默认值没有 weak 的 keys，它就会将所有的带有默认值的 tables 设定为永久存 在。在第二种方法中，我们使用不同的 metatables 来保存不同的默认值，但当我们重复 使用一个默认值的时候，重用同一个相同的 metatable。这是一个典型的记忆技术的应用:

local metas = {}
setmetatable(metas, {_mode = \"v\"})
 
 
function setDefault (t, d)
   local mt = metas[d]
   if mt == nil then

   mt = {_index =function () return d end} 
   metas[d]= mt -- memoize
 
end
 setmetatable(t, mt)
end

       这种情况下，我们使用 weak vaules，允许将不会被使用的 metatables 可以被回收。 把这两种方法放在一起，哪个更好?通常，取决于具体情况。它们都有相似的复杂 性和相似的性能。第一种方法需要在每个默认值的 tables  中添加一些文字(一个默认的入口)。第二种方法需要在每个不同的默认值加入一些文字(一个新的表，一个新的闭包，metas 中新增入口)。所以，如果你的程序有数千个 tables，而这些表只有很少数带有不同默认值的，第二种方法显然更优秀。另一方面，如果只有很少的 tabels 可以共享相同 的默认vaules，那么你还是用第一种方法吧。