Lua垃圾回收及内存优化

当处理Lua资源时，我们也应该遵循提倡用于地球资源的3R原则——Reduce, Reuse and Recycle，即削减、重用和回收。

削减是最简单的方式。有很多方法可以避免使用新的对象，例如，如果你的程序使用了太多的表，可以考虑改变数据的表述形式。一个最简单的例子，假设你的程序需要操作折线，最自然的表述形式是：

polyline ={    { x = 10.3, y = 98.5 },    { x = 10.3, y = 18.3 },    { x = 15.0, y = 98.5 },    --...}

尽管很自然，这种表述形式对于大规模的折线来说却不够经济，因为它的每个点都需要用一个表来描述。第一种替代方式是使用数组来记录，可以省点内存：

polyline ={     { 10.3, 98.5 },     { 10.3, 18.3 },     { 15.0, 98.5 },     --...}

对于一个有一百万个点的折线来说，这个修改可以把内存占用从95KB降低到65KB。当然，你需要在可读性上付出代价：p[i].x比p[i][1]更易懂。

另一个更经济的做法是使用一个数组存储所有x坐标，另一个存储所有y坐标：

polyline ={    x = { 10.3, 10.3, 15.0, ...},    y = { 98.5, 18.3, 98.5, ...}}

原有的

p[i].x    

现在变成了

p.x[i]    

使用这种表述形式，一百万个点的折线的内存占用降低到了24KB。

循环是寻找降低垃圾回收次数的机会的好地方。例如，如果在循环里创建一个不会改变的表，你可以把它挪到循环外面，甚至移到函数外作为上值。试对比：

function foo (...)     for i = 1, n do          local t = {1, 2, 3, "hi"}          -- 做一些不会改变t表的事情          --...     endend

和

local t = {1, 2, 3, "hi"} -- 创建t，一劳永逸function foo (...)    for i = 1, n do        --做一些不会改变t表的事情        --...    endend

相同的技巧亦可用于闭包，只要你不把它们移到需要它们的作用域之外。例如下面的函数：

function changenumbers (limit, delta)    for line in io.lines() do        line = string.gsub(line, "%d+", function (num)            num = tonumber(num)            if num >= limit then return tostring(num + delta) end            -- 否则不返回任何值，保持原有数值        end)        io.write(line, "\n")    endend

我们可以通过将内部的函数移到循环外面来避免为每次迭代创建新的闭包：

function changenumbers (limit, delta)    local function aux (num)        num = tonumber(num)        if num >= limit then return tostring(num + delta) end    end    for line in io.lines() do        line = string.gsub(line, "%d+", aux)        io.write(line, "\n")    endend

但是，我们不能把aux移到changenumbers函数之外，因为aux需要访问limit和delta。

对于多种字符串处理，我们可以通过使用现有字符串的索引来减少对创建新字符串的需要。例如，string.find函数返回它找到指定模式的位置索引，而不是匹配到的字符串。通过返回索引，它避免了在成功匹配时创建新的字符串。当有必要时，程序员可以通过调用string.sub来获取匹配的子串[1]。

当我们无法避免使用新的对象时，我们依然可以通过重用来避免创建新的对象。对于字符串来说，重用没什么必要，因为Lua已经为我们做了这样的工作：它总是将所有用到的字符串内部化，并在所有可能的时候重用。然而对于表来说，重用可能就非常有效。举一个普遍的例子，让我们回到在循环里创建表的情况。这一次，表里的内容不再是不变的。通常我们可以在所有迭代中重用这个表，只需要简单地改变它的内容。考虑如下的代码段：

local t = {}for i = 1970, 2000 do    t[i] = os.time({year = i, month = 6, day = 14})end

下面的代码是等同的，但是重用了这张表：

local t = {}local aux = {year = nil, month = 6, day = 14}for i = 1970, 2000 do    aux.year = i    t[i] = os.time(aux)end

实现重用的一个尤其有效的方式是缓存化[2]。基本思想非常简单，将指定输入对应的计算结果存储下来，当下一次再次接受相同的输入时，程序只需简单地重用上次的计算结果。

LPeg，Lua的一个新的模式匹配库，就使用了一个有趣的缓存化处理。LPeg将每个模式字符串编译为一个内部的用于匹配字符串的小程序，比起匹配本身而言，这个编译过程开销很大，因此LPeg将编译结果缓存化以便重用。只需一个简单的表，以模式字符串为键、编译后的小程序为值进行记录。

使用缓存化时常见的一个问题是，存储计算结果所带来的内存开销大过重用带来的性能提升。为了解决这个问题，我们可以在Lua里使用一个弱表来记录计算结果，因此没有使用到的结果最终将会被回收。

在Lua中，利用高阶函数，我们可以定义一个通用的缓存化函数：

function memoize (f)    local mem = {} -- 缓存化表    setmetatable(mem, {__mode = "kv"}) -- 设为弱表    return function (x) -- ‘f’缓存化后的新版本        local r = mem[x]        if r == nil then --没有之前记录的结果？            r = f(x) --调用原函数            mem[x] = r --储存结果以备重用        end        return r    endend

对于任何函数f，memoize(f)返回与f相同的返回值，但是会将之缓存化。例如，我们可以重新定义loadstring为一个缓存化的版本：

loadstring = memoize(loadstring)

新函数的使用方式与老的完全相同，但是如果在加载时有很多重复的字符串，性能会得到大幅提升。

如果你的程序创建和删除太多的协程，循环利用将可能提高它的性能。现有的协程API没有直接提供重用协程的支持，但是我们可以设法绕过这一限制。对于如下协程：

co = coroutine.create(function (f)    while f do        f = coroutine.yield(f())    endend)

这个协程接受一项工作（运行一个函数），执行之，并且在完成时等待下一项工作。

Lua中的多数回收都是通过垃圾回收器自动完成的。Lua使用渐进式垃圾回收器，意味着垃圾回收工作会被分成很多小步，（渐进地）在程序的允许过程中执行。渐进的节奏与内存分配的速度成比例，每当分配一定量的内存，就会按比例地回收相应的内存；程序消耗内存越快，垃圾回收器尝试回收内存也就越快。

如果我们在编写程序时遵循削减和重用的原则，通常垃圾回收器不会有太多的事情要做。但是有时我们无法避免制造大量的垃圾，垃圾回收器的工作也会变得非常繁重。Lua中的垃圾回收器被调节为适合平均水平的程序，因此它在多数程序中工作良好。但是，在特定的时候我们可以通过调整垃圾回收器来获取更好的性能。通过在Lua中调用函数collectgarbage，或者在C中调用lua_gc，来控制垃圾回收器。它们的功能相同，只不过有不同的接口。在本例中我将使用Lua接口，但是这种操作通常在C中进行更好。

collectgarbage函数提供若干种功能：它可以停止或者启动垃圾回收器、强制进行一次完整的垃圾回收、获取Lua占用的总内存，或者修改影响垃圾回收器工作节奏的两个参数。它们在调整高内存消耗的程序时各有用途。

“永远”停止垃圾回收器可能对于某些批处理程序很有用。这些程序创建若干数据结构，根据它们生产出一些输出值，然后退出（例如编译器）。对于这样的程序，试图回收垃圾将会是浪费时间，因为垃圾量很少，而且内存会在程序执行完毕后完整释放。

对于非批处理程序，停止垃圾回收器则不是个好主意。但是，这些程序可以在某些对时间极度敏感的时期暂停垃圾回收器，以提高时间性能。如果有需要的话，这些程序可以获取垃圾回收器的完全控制，使其始终处于停止状态，仅在特定的时候显式地进行一次强制的步进或者完整的垃圾回收。例如，很多事件驱动的平台都提供一个选项，可以设置空闲函数，在没有消息需要处理时调用。这正是调用垃圾回收的绝好时机（在Lua 5.1中，每当你在垃圾回收器停止的状态下进行强制回收，它都会恢复运转，因此，如果要保持垃圾回收器处于停止状态，必须在强制回收后立刻调用collectgarbage("stop")）。

最后，你可能希望实施调整回收器的参数。垃圾回收器有两个参数用于控制它的节奏：第一个，称为暂停时间，控制回收器在完成一次回收之后和开始下次回收之前要等待多久；第二个参数，称为步进系数，控制回收器每个步进回收多少内容。粗略地来说，暂停时间越小、步进系数越大，垃圾回收越快。这些参数对于程序的总体性能的影响难以预测，更快的垃圾回收器显然会浪费更多的CPU周期，但是它会降低程序的内存消耗总量，并可能因此减少分页。只有谨慎地测试才能给你最佳的参数值。

---

[1] 如果标准库提供一个用于对比两个子串的函数可能会是一个好主意，这样我们无需将子串解出（会创建新的字符串）即可检查字符串中的特定值。

[2] 缓存化，原文memoize

---------------------------

lua垃圾回收机制

一、检测lua内存泄漏：

注：使用“collectgarbage("collect")”，局部变量v被回收，my_list没有被回收。

注：局部变量v占用的内存被回收。

注：将my_list置为nil，使用“collectgarbage("collect")”可以回收。

总结一: 如何监测Lua的编程产生内存泄露:

1.       针对会产生泄露的函数,先调用collectgarbage("count"),取得最初的内存使用

2.       函数调用后, collectgarbage("collect")进行收集, 并使用collectgarbage("count")再取得当前内存, 最后记录两次的使用差

3.       从test1的收集可看到, collectgarbage("collect")被调用，并不保证一次成功, 所以, 大可以调用多次

总结二: 如何避免Lua应用中出现的内存使用过大行为:

1.       当然是代码实现不出现泄露

2.       在测试中，其实还发现, Lua中被分配的内存，其实并不会自动回收(个人估计要么就是Lua虚拟机没有做这个事情，要么就是回收的时机是在C层), 所以, 为了避免内存过大, 应用的运行时，可能需要定期的（调用collectgarbage("collect")，又或者collectgarbage("step")）进行显式回收。

 ----------------------------------------------------------------------------------

【使用LUA开发游戏，发现内存耗费成倍增长】http://blog.sina.com.cn/s/blog_a17b071c0101itua.html

内存随着时间成倍增加，这个感觉应该是和堆栈分配有关系，但是看我们LUA框架代码，大部分用到LUA地方都有进行释放了呀。。。

挨个对照COCOS2D-X提供的LUA框架和我们的LUA框架，发现在一般的方法，比如执行字符串，执行文件，等等ExecuteString，ExecuteScriptFile，ExecuteGlobalFunction函数写法都一样，于是范围缩小到我们自己写的几个函数里面。我们自己封装的执行对话框内部函数ExecuteTableFunction，GetTableFuntion等几个，仔细阅读代码后，终于发现问题了：

1）堆栈用完没有及时恢复

2）没有及时使用垃圾回收
 解决方案

1）在函数异常返回或者正常处理返回时，堆栈要进行恢复：

lua_pop(L, 1);

// 恢复之前的栈顶位置

lua_settop(L, 0);

2）在调用lua_pcall()时，要调用lua_gc(L, LUA_GCCOLLECT, 0);进行垃圾回收；

在这些修改后，重新进行编译运行，这个时候再打印内存，发现就很OK了：