那么, 有没有一些有效的解决办法, 来解决这个这个隐患呢, 答案就是collectgarbage. collectgarbage就是开放给Lua开发人员, 用于监听Lua的内存使用情况(collectgarbage("count")), 同时,它还提供了collectgarbage("collect"),允许在适当的时候进行显式的回收.
现在,通过测试代码来看看,如何玩转collectgarbage.
首先,为了有明显的对比, 先来看没有产生泄露的情况, 运行以下的test1(代码如下):
运行结果如下:
这里看到 , 被 local 声明的 colen 加了 5000 数组 , test1 调用后 , 内存增加了大概 300K(25906K-25620K).
运行结果:
( 为了保证内存的稳定 , 以上注意 mem 被调用了多次 , 再第 2 次 , 可以看到内存开始下降 , 最后 , 大概在 25618K 稳定下来)
好了,现在运行有泄露的test2(代码如下), test2跟test1相比,只有一处不同:就是colen被误声明为全局:
结果:
为了保证函数回收被执行,这次,总共调用了 7 次 mem 函数(看以上打印行数) , 那么,从上面的结果我们看 , 很不幸 , 从第 1 次,到最后第 7 次 , 内存都还是稳定在 25905K 左右 , 也就是说 , 跟调用 test2 前相比,即使 Lua 进行了内存回收 , 内存却不会将下来 看来 , 这 300K(25906K-25620K) 内存 , 由于已放到了全局函数中,是永远没有机会被回收到了 !
总结一: 如何监测Lua的编程产生内存泄露:
1. 针对会产生泄露的函数,先调用collectgarbage("count"),取得最初的内存使用
2. 函数调用后, collectgarbage("collect")进行收集, 并使用collectgarbage("count")再取得当前内存, 最后记录两次的使用差
3. 从test1的收集可看到, collectgarbage("collect")被调用,并不保证一次成功, 所以, 大可以调用多次
总结二: 如何避免Lua应用中出现的内存使用过大行为:
1. 当然是代码实现不出现泄露, (废话*&%$()
2. 在测试中,其实还发现, Lua中被分配的内存,其实并不会自动回收(个人估计要么就是Lua虚拟机没有做这个事情,要么就是回收的时机是在C层), 所以, 为了避免内存过大, 应用的运行时,可能需要定期的(调用collectgarbage("collect"),又或者collectgarbage("step"))进行显式回收。