爱华网那么,有没有一些有效的解决办法,来解决这个这个隐患呢,答案就是collectgarbage.collectgarbage就是开放给Lua开发人员,用于监听Lua的内存使用情况(collectgarbage("count")),同时,它还提供了collectgarbage("collect"),允许在适当的时候进行显式的回收.
现在，通过测试代码来看看，如何玩转collectgarbage.
首先,为了有明显的对比,先来看没有产生泄露的情况,运行以下的test1(代码如下):
运行结果如下:
这里看到, 被local 声明的colen加了5000数组, test1调用后, 内存增加了大概300K(25906K-25620K).现在，我们来做内存回收(调用mem函数, 代码如下):
运行结果:
(为了保证内存的稳定,以上注意mem被调用了多次, 再第2次, 可以看到内存开始下降, 最后,大概在25618K稳定下来)好了, 从最初的25620K,到回收后的25618K, 两者并没有发生变化(还少了2K，嘿嘿, 这应该是误差了), 也就是说,函数test1的执行，并没有产生无法回收的内存，没有泄露出现.
好了，现在运行有泄露的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")）进行显式回收。
