• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    公众号

Lua内存管理

原作者: [db:作者] 来自: [db:来源] 收藏 邀请

lua内存泄漏查证 

 
本文主要介绍某项目脚本(lua)部分内存泄漏的查证与处理过程,希望对大家有点
帮助。需要说明的是,lua本身并不存在真正的内存泄漏,只是因为使用上面的原
因导致无法gc,从而导致逻辑上的泄漏:)。
 参考GCObject的声明可以发现,lua中的复杂数据类型变量的传递都是基
于引用的。当lua从根开始gc扫描的时候,只要还有一个地方有对此变量的引用,那
么这个变量就不会被collect。这种情况造成的危害取决于多大程度上依赖于引
用,如果有适当的间接层/弱引用来隔离这个问题,可能问题会有所缓解。

 以下是一些常见的错误引用情景:
 1. 本应该local 的变量进入global空间或者module空间了(忘记写local),如果
这是一个table/function/udata等类型的变量的话,非常不幸的,这个变量将不会
被正确gc了 ----除非你再显式的释放。这是非常容易犯的错误,一直在想为什么
lua变量不是默认local呢? 当然这个话题会引发另外一场争论。
local function test_user(id)
 userobj = get_user_by_id(id) --这里总是会有一个玩家对象泄漏
 print("only test", userobj:get_name())
end

 2. c/c++部分调用的lua_ref是否有正常lua_unref释放? 通过
debug.getregistry()可以查到这些ref.

 3. 其他各种各样的实际bug造成的泄漏。

 当怀疑系统有泄漏以后,我们可以怎么查到这些泄漏呢?我强烈建议大家建立一
个weak table, 把你所有创建过的能够称之为资源的,包含但不限于“战斗对象,
玩家,npc,物品,场景,邮件”等等对象全部扔到这个table里面。当你知道玩家
已经下线、战斗已经销毁了,但通过连续的强制full gc以后weak table里面还有
这个变量,这就证明了这个变量的引用没有被完全释放,于是问题就被发现了,我
们又有事情干了@_@。

 知道有泄漏是比较容易的,能够完全揪出来就不是很容易了。是的,它究竟在哪
儿呢? 一开始在此项目里面也是先发现比如某npc泄漏了,然后就去查代码,看看
究竟哪个地方写得不对。这种方式效率极低,基本上查不到什么问题。在迟一点的
时候才使用现在的方案:从_G深度遍历所有的table、metatable、funciton's
upvalue、function's env、registentry(lua_ref)。 目前所知的所有引用必定存
在于这几个空间, 遍历完成以后一定可以找到那个“迷失了的引用”。 这种方式在
脚本层就可以完成所有事情,甚至你可以在运营环境中在线查证,其遍历的速度
是非常快的,但内存开销非常大(:,可以考虑一边遍历一边gc,当然还要记得
避免重复搜索。 在应用此方案以后,此项目解决了脚本中所有的泄漏问题。

 一点总结:1.如果系统性能还能够承受的话,建议不要直接引用对象,可以多做
一层间接层。2.lua里面的弱引用是非常有用的。3.比较大的物理内存是必要的,
这可以为大家查证问题争取足够多的时间:) 4.可以把查找泄漏的部分写入到关机
逻辑里面,每次关机的时候自动查找泄漏,然后出具报告。
游戏逻辑层在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类似的)分代, 不同代的数据使用不同的保存,封装和清除策略,保证在最大效率的情况下准确的完成垃圾收集!


鲜花

握手

雷人

路过

鸡蛋
该文章已有0人参与评论

请发表评论

全部评论

专题导读
上一篇:
【原创】大叔经验分享(77)openresty(nginx+lua)发http请求发布时间:2022-07-22
下一篇:
cocosluacompile加密lua文件发布时间:2022-07-22
热门推荐
热门话题
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服(服务时间 9:00~18:00)

在线QQ客服
地址:深圳市南山区西丽大学城创智工业园
电邮:jeky_zhao#qq.com
移动电话:139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap