日期：2014.7.16
PartⅡ 17
Weak Tables and Finalizers
Lua实现的是自动的内存管理。程序可以创建对象，可是没有现成的函数来实现删除对象。Lua使用 garbage collection(垃圾回收机制？)来删除变成gargage的对象，这一特性带来了很大的便利，不再深陷于内存回收，并且可以避免很多因为内存回收而引发的一系列问题，如悬垂指针和内存泄漏。
本章节提到的Weak Tables和Finalizers是lua提供的一个特性，允许用户参与到lua的garbage collector机制中。Weak Table允许回收程序依旧在使用的对象，而finalizer则允许回收garbage collector没有完全或者说直接控制到的对象。
17.1 Weak Tables
garbage collector只会回收那些确定为garbage的对象，但是它推断不出用户认为哪些变量是garbage。lua中任何全局变量都不会是garbage，尽管程序没有再使用过这些变量Lua也不会自动回收。这也是这本书开篇讲到过的，全局变量在不使用的时候赋值为nil，这时系统才会自动回收内存。因此说Lua是推断不出用户的主观行为。
有的时候仅仅是清除了相关的引用是不够的，when you want to keep a collection of all live objects of some kind in your program.This task seems simple:all you have to do is to insert each new object into the collection.However ,once the object is part
of the collection,it will never be collected.这段的意思到底是什么呢？我们需要做的仅是将新的对象插入到collection中，但是一旦我们这些对象成为了collection的一部分便再也不会被collected了。Lua并不知道这样的引用不能去阻止Lua对对象的回收，除非用户告诉Lua？
Weak table就是用来告知Lua某个引用不能去阻止Lua对某个对象的回收的机制。一个weak reference就是对一个garbage collector没有管理的对象的引用。如果所有指向某个对象的引用是weak的，那么这些对象将会被回收且这些引用也会被系统删除。weak table就是lua用来实现weak reference的，该table里面的存储的都是weak的。这就意味着，如果某个对象仅是受weak table控制，那么lua最终会回收这个对象。
Table拥有key和value，这两个值都可以是任何类型的对象。在一般情况下，garbage collector不会回收作为table的key或者value的对象，这就是说table的key和value都是强引用(strong reference)，这就会影响lua回收他们所指向的对象。而在weak table中key和value都可以是weak的，这就意味着weak table会有三种类型：key是weak而value不是；value是weak的而key不是；key和value都是weak的。不管weak
table是何种类型，只要key或者value被回收了那么整个table里面的内容都会被回收掉。
涉及到元表。元方法 __mode 赋予了table的弱特性，该方法的值类型为string类型。当值为"k",表示key是weak的；当值为"v",表示value是weak的；当值为"kv",则表示key和value都是weak的。
e.g.
a = {}
--此时表示key为weak
b = { __mode = "k"}
setmetatable(a,b)
key = {}
a[key] = 1
key = {}
a[key] = 2
collectgarbage()
for k,v in pairs(a) do
print(v)
end
在这个例子中，__mode的值是"k",表明这个table以key为weak，具体的例子中，对key的第二次赋值重写了key第一次复制时的引用，所以但进行内存回收时将第一次赋值的key回收了，而第二次赋值的没有。。。这里的key是一个table，是一个对象所以可以被回收。
要注意的是只能从weak table回收对象，而对于如numbers和booleans等变量，则不能回收。即假如我们以一个number作为tablekey，那么collector将不会移除这个key，当然当table的value是weak的，不管key是否是weak亦不管key的类型是不是对象，当value被回收了整个table里面的元素都会被移除了。
如果key是string类型这里需要特殊考虑：尽管string是可回收的，从实现角度看，其不像其余可回收的对象。像table和thread都是明确的创建的，如我们写a = {},就明确的创建了一个table。然而，"a" .. "b" 此时会创建一个string型变量嘛？假如此时系统中已经存在一个"ab"了怎么办？lua会继续创建一个嘛？编译器会在运行程序前就创建一个string型变量嘛？从程序员角度来看，string是变量而不是对象。因此，和number或boolean一样，string也不会从weak
table中移除(除非value是weak的)。
17.2 Memoize Functions
记忆函数？
A common programming technique is to trade space for time?啥意思？？(用空间换取时间？？)能通过记住该函数的运算结果进而提升一个函数的运行效率，效率体现在当用同一个参数调用该函数的时候，直接返回已经记住的结果。这应该就是前文讨论的模块的设计思路--同一个模块一般情况下只会加载一次。
e.g.
local results = {}
function mem_loadstring( s )
local res = results[s] --从table中访问该参数
if res == nil then --如果该table中没有该值
res = assert(load(s))
results[s] = res --将该值存入table中，下次访问的时候直接返回该值
end
return res
end
书上提到了存储这些可能会占用很大的空间，但是带来了效率的提升。这差不多是trade space for time 这句话的解释吧。有的时候，这也会带来不必要的浪费，比如说有些时候可能会以同一个参数频繁的调用某个函数，但是某些时候仅仅会调用一次，假如一直存储着这些信息这样就带来了不必要的浪费。一般情况下，上例中的results会累积存储每次以新参数调用该函数的信息，这样下去总会在某个时间点耗尽系统内存。此时上文提到的weak table就提供了解决方案。如果resultes中有weak的value，那么每次garbage-collection的回收就会移除在该回收点没有使用的value，这也意味着该results里面存储的信息都会被释放掉。
e.g.
local results = { }
--表示此时table中的value是weak的
setmetatable(results,{__mode = "v"})
function mem_loadstring( s ) <同上>
end
因为函数的参数是string型的(table的key)，所以我们可以考虑将table设置为true weak的
e.g.
setmetatable(results,{__mode = "kv"})
结果是一样的。
这个机制也适合在我们想让某些对象是唯一值的情况。例如，用table表示颜色的时候，有三个字段red，green，blue,通常我们会这样创建
e.g.
function createRGB( r,g,b )
return {red = r,green = g,blue = b}
end
在引入了我们现在讨论的这个机制后：
e.g.
local results = {}
setmetatable(results,{__mode = "v"})
function createRGB( r,g,b )
local key = r .. "-" .. g .."-" b --保持key的唯一性
local color = results[key]
if color == nil then
color = {red = r,green = g,blue = b}
results[key] = color
end
return color
end
这样就保证每次以同参数创建的table都是同一个。引入了这一机制后，用户也可以直接比较通过两个color了，假如是同参数创建的那么就是同一个table，此时比较是相等的。否则就一定是不相等的。
17.3 Object Attributes
对象属性
另一个使用到了weak table的地方是将对象与其属性向关联起来。很多时候我们都需要将一些属性附加至对象上：函数的名字，table的默认值，数组的大小等等。
当对象是table的时候，我们可以将这些属性以一个特殊的key存储在自身这个table里面。如我们前文所采用的，最简单又是最唯一的key就是创建一个新的对象(通常是一个table)。但是当对象不是table的时候，这些属性就不能存储在自身，这个时候我们就需要采取别的方法来实现我们的要求了。
用额外的一个table使对象与其属性绑定起来，以对象为key，其属性为value。这个table将保存所有类型对象的属性，这也带来了困扰---不能回收这些对象了，因为这些对象被以key来使用。此时我们就需要引入weak key机制，使用weak key是考虑到，使用weak key不会影响系统回收那些没有被引用的对象；而从另一方面来考虑，如果是使用weak value，一旦value被回收了，与之相关联的对象也会被回收，这是我们不期望的。
17.4 Revisiting Tables with Default Values
我们已经讨论过如何实现创建一个带默认值的table。现在以我们在讨论的weak table来回顾一番这个主题。这里将会涉及到两个解决方案：object attributes and memorizing。
首先第一个方案：使用weak table来绑定table和它的默认值：
local defaults = {}
--设置defaults的key为weak
setmetatable(defaults,{__mode = "k"})
--在访问table元素的时候，如果没有该key则返回defaults的值，这里的参数是table，保持唯一性
local mt = {__index = function ( t )
return defaults[t]
end}
--设置table的默认值，以table本身为defaults这个table的key
function setDefault( t,d )
defaults[t] = d
setmetatable(t,mt)
end
这里如果defaults没有设置weak key，那么该table会将z在程序运行期间永久保存所有table的默认值。
此时假如我们这样操作：
e.g.
local a = {}
setDefault(a,1)
--那么我们访问一个a中不存在的元素
print(a.x) --1 使用其默认值。
第二个方案：
e.g.
local metas = {}
--这里weak table设置value为weak的
setmetatable(metas,{__mode = "v"})
function setDefault( t,d )
--每次从访问这个weak table，看是否有这个默认值的table
local mt = metas[d]
if mt == nil then
--如果没有则创建table作为t的元表
mt = { __index = function ( )
return d
end}
--以默认值为key保存这个元表
metas[d] = mt
end
--设置t的元表，带默认参数d
setmetatable(t,mt)
end
在这里我们为每个不同的默认值设置不同的元表，但是我们会在每次使用同一个默认参数的时候复用同一个元表。
这里将value设置为weak的主要是为了能回收这些没有用到的元表。
针对不同情况，这两种方案有不同的性能表现。第一个方案需要为每个不同默认值的table准备内存空间(存储这些默认值)；第二个方案则为不同的默认值准备空间(该方案以是否默认值不同而来设计的，即假如多个table共用一个默认值，那么此时只会存储一个值)。因此当我们的程序有数千个table但是只需要准备少数几个默认值，那么适合使用第二套方案；而如果table较少，所用的默认值也少，那么就适合使用第一套方案。
17.5 Ephemeron Tables
蜉蝣table？？
设想这种情况：一个table其key是weak的，而其value又与其key相关联。
这种情况似乎是有可能的。例如，有一个常数函数构造工厂？，该函数接受一个对象参数并返回该对象的一个函数，无论何时访问这个函数都是返回该对象：
e.g.
function factory( o )
return function ( ... )
return o
end
end
使用我们之前讨论的memorizing
do
local mem = {}
setmetatable(mem,{__mode = "k"})
function factory( o )
local res = mem[o]
if not res then
res = function ( ... )
return o
end
mem[o] = res
end
return res
end
end
这样就不会每次都创建新的函数而增加开销，直接从mem这个weak table中寻找需要的信息。这一段的内容有点让人混淆：该table是key为weak的，而value不是，作者说value不会被collect，因为value是对每个function的强引用(这里指该factory)。之前提到的只要value或者key是weak的，一旦其中一个被collect了，那么该table里的都会被移除掉，书上说的是(whole entry disappears)难道指的是移除而不是被回收吗？
Lua5.2版本中提出了一个概念：ephemeron tables.指的是key是weak的，而value是strong的table。在ephemeron table中，key的可访问性影响着与之相关联的value的可访问性。The reference to v is only strong if there is some strong reference to k.如果对k有强引用那么对v也只能是强引用的，否则就会被移除，即便v直接或间接的引用了k。
17.6 Finalizers
Lua的garbage collector不仅可以用来收集lua的对象，同时也可以用来释放资源。现有多种语言提供finalizer的机制。finalizer指的是一个与一个对象相联系的当该对象要被collected时调用的一个函数：
e.g.
o = {x = "hi"}
setmetatable(o,{__gc = function (o )
print(o.x)
end})
o = nil
collectgarbage() --print hi
当我们调用collectgarbage()方法进行回收的时候，调用了与o关联的finalizer。
从上可以看得出，lua实现finalizer是通过设置元方法：__gc来实现的。
需要注意的：在设置元表的时候，需要先设置其元方法，也可以说是在设置元表前先标记对象。这点其实与之前讲元表-元方法的时候类似，如果先设置元表，再定义元方法其实lua是不会去执行我们定义的元方法的。因此假如上例这样实现：
e.g.
o = {x = "hi"}
mt = {}
setmetatable(o,mt)
mt.__gc = function (o )
print(o.x)
end
o = nil
collectgarbage() -- 这里不会打印任何东西,还可能引发不可预计的错误
而如果非要在设置完元表再设置元方法，可以先在元表内部给__gc 这个字段赋值(可以是任何类型)再在设置完元表后定义元方法：
e.g.
o = {x = "hi"}
mt = {__gc = true}
setmetatable(o,mt)
mt.__gc = function (o )
print(o.x)
end
o = nil
collectgarbage() --hi 这样就能正确打印出来
lua的collector依据标记的顺序来处理一次finalize多个对象的finalizer
e.g.
mt = { __gc = function ( o )
print(o[1])
end}
list = nil
for i=1,3 do
list = setmetatable({i,link = list},mt)
end
list = nil
collectgarbage() -- 3 2 1
3是最后被标记的，所以最先被打印出来。
当调用一个finalizer的时候，该函数会调用标记的对象作为自己的参数。而其实此时该对象已经被回收掉了，而在该finalizer的函数体内实现了“复活”，因此在该finalizer结束执行前还是可以访问到作为其参数的对象的。“复活”这一特性是可以传递的：
e.g.
A = {x = "this is A"}
B = {f = A}
setmetatable(B,{__gc = function (o) print(o.f.x) end})
A,B = nil
collectgarbage()
这个例子很好的解释了传递这一特性，A已经被回收了，但是并没有设置finalizer，而B的一个value为A，B设置了finalizer。当A，B都被赋值为nil强制回收之后，在B的finalizer内部B实现了“复活”，而该特性传递给了B的valueA，与之相应的A也实现了复活。
因为“复活”这个机制的影响，对象被回收其实要经历两个阶段，第一个阶段回收器会对有finalizer的对象进行确认还没有调用它的finalizer，并“复活”该对象然后执行其finalizer，一旦该finalizer被执行了lua便会标记该对象为已经finalize了。第二个阶段回收器检测到该对象已经被finalize了，就会删除该对象。因此为了确保程序中所有的garbage都被回收了，需要强制调用collectgarbage这个函数两次。
因为lua会标记对象是否已经被finalize，所以对象的finalizer只会调用一次。如果直到程序运行结束某个对象都没有被回收，lua将会在整个lua的state被关闭之前调用其finalizer。
另一个有趣的机制是：可以实现每次当lua完成一个垃圾回收就调用一个给定的函数。这里的实现原理是，尽管finalizer只会实现一次，但是可以在每次执行的时候重新创建一个新的对象去运行下一个finalizer：
e.g.
do
local mt = {__gc = function ( o )
print("new cycle")
setmetatable({},getmetatable(o)) -- 每次执行finalizer就重新创建一个对象设置为同一个元表，同一个元方法
end}
setmetatable({},mt)
end
collectgarbage()
collectgarbage()
collectgarbage()
而对于拥有finalizer的对象和weak table之间的关系这里也需要讨论一番：回收器会在“复活”之前清理weak table的values，而其key则是在“复活”之后进行清理：
e.g.
wk = setmetatable({},{__mode = "k"})
wv = setmetatable({},{__mode = "v"})
o = {}
wv[1] = o;wk[o] = 10
setmetatable(o,{__gc = function ( o )
print(wk[o],wv[1])
end})
o = nil
collectgarbage() --10 nil
print(wk[o]) --nil
以上例子做出来很好的解释。wk其key是weak的，而wv其value是weak的。设置好元表之后，执行回收可以看到，打印出了10而没有打印出wv的元素，因为在垃圾回收之前wv就已经被清理了，而wk在回收之后清理。这也合理的解释了为什么我们使用weak key的table来存储对象的属性，因为设计中可能finalizer可能也需要访问这些属性。