游戏逻辑层在Lua中的内存泄漏与防范

Lua会造成内存泄露的表征分析:

#因素一:(实例型)实体资源的创建持有者和调用者，相互之间如果太过信任,那么对调用者就会形成过高的要求,创建者可以让任意的调用者进行任意的create,调用者消费后以为创建者会管理(销毁),但其实并非如此,比如有这样一个实体管理器xxxManager,它有接口createXXX/removeXXX, 那么，创建和销毁的权利都丢给了调用者,如果调用者光create而不remove,那么,xxxManager就会产生越来越多的xxx(xxx可真多丫)，从而产生了内存泄露

#因素二:逻辑层的角色数据如果没有跟随角色，将会导致前者和后者在生命周期上非不严格对应, 或者说角色对自己的数据的持有太松散,这样，如果角色在玩家下线后，即使被roleManager销毁了，但它所对应的数据，并没有得到销毁, 这样，也产生了泄露

#因素三:singleton单实例对象,本身是在内存中持久存在的, 这样，从内存泄露的角度上看，它们对数据的持有的风险是很高的, 如果它们中的任意一个，有这样的一个接口addPlayer(player), 而在player下线时也没有进行即时的清除, 那么，泄露又产生了

#因素四:如果框架层接口太过于开放的话，也会给脚本层lua带来泄露的风险, 最典型的比如计时器，lua的某个方法启动了一个计时器而又忘了关掉它, 这就麻烦了.

因此, 虽然lua有gc，但是脚本中的游戏逻辑层，也会产生内存泄露，并且，泄露还很容易，泄露的地方还很多！

根源是什么?

这究竟是怎么回事呢? 由于以上的泄露，其实都是逻辑泄露(跟c/c++的泄露本质不同),那么我们可以从设计上，来探根源:

#每个层自身职责的定义如果不够严谨，它们之间存在一些不必要的耦合的话,这里表现为(框架)层与(脚本)层,(实体)层与(逻辑)层,(全局资源层)与(逻辑)层,以上的泄露就很容易产生, 举个简单例子：实体由实体层管理持有, 而逻辑层(在任何一个接口)却能直接的去创建,或者销毁一个资源实体，实体的生命横跨实体层和逻辑层, 生命周期发生了外泄, on the other hand,从设计的角度书，就是实体让两个层产生了耦合!

#实体资源本应该有的强依赖关系没有建立起来, 在游戏中最重要的就是角色和角色数据(比如任务),material,task,等，本身并不能独立存在,它们的生命周期完全依赖于角色的生命周期(原型数据除外),所以，必须理清所有的实体的生命周期，已经它们之间的联系，该强耦合的强耦合.

#对逻辑层singleton的全局性对象持有实体资源的风险意识不够,根据上面一条，逻辑层全局子系统不能够直接持有任何一个实体(即使是原型).

设计上怎么做?

也就是说，我们在搭建脚本层的游戏框架上的时候，就首先对内存泄露有足够和清醒的认识, 在设计上, 做出更好的规划，让脚本层更健壮, 针对以上的原因，我们很容易的，有这样的做法:

#实体管理器如果是本身持有了实体，那么，就不应该开发create/remove接口，而是选择直接

#所有实体资源,主要是目前的玩家逻辑数据, 必须直接帮在role上，确保role的销毁比如会引发它们的销毁

#全局资源性的数据，可以考虑放在weak table中

监测机制的产生?

监测，就是必须存在这样一个机制:我们能够利用某些接口/命令,清晰全面的得知脚本层在是否存在，在哪里存在内存泄漏.毕竟,逻辑型泄漏的代码，很容易就可以写出来并且不能100%的杜绝,建立起这样一个机制，在分析游戏服务器端的健壮性，稳定性上，都是很有帮助的.

#计数法. 在垃圾收集中,计数法是比较原始的算法, 效率低，不能解决循环引用. 不过,如果我们把它用在实体管理器与实体，主实体与非主实体上，有可能可行，因为，这些对象间，并没有产生循环引用,另外,我们也通过在不同类型的类上采用不同的时间间距，来达到比较好的性能. 也就是说，引入计数法,即可监测，其实还可以做垃圾收集

#对全局资源, 可以考虑引入mark-sweep算法/复制算法来管理,

如何让垃圾收集更加的高效?

lua gc 采用mark-sweep算法, 效率不高,并且好像没有看到有自己回收的地方, 如果在游戏应用层调用collectgarbage("collect"),不可避免会影响服务器的性能,所以, 我们可以对lua中的模块进行(javaGC类似的)分代, 不同代的数据使用不同的保存,封装和清除策略,保证在最大效率的情况下准确的完成垃圾收集!

BTW,这里有另一篇对Lua的内存泄露文章,供大家开阔视野:

Lua内存泄露与查找