引子

最近用機器人做NPC的壓力測試,突然發(fā)現(xiàn)一臺機器能支持的機器人數(shù)量劇減,而且運行一段時間后整臺機器直接內(nèi)存耗光死機.經(jīng)過觀察,發(fā)現(xiàn)1個機器人在運行一段時間之后內(nèi)存能占用到120M之多,而且還在不斷增加,同時內(nèi)存無法手動回收.
以前1個機器人大概消耗10M-20M的內(nèi)存,這次的消耗明顯異常了,所以初步判斷邏輯上存在lua對象泄漏:在某些沒有注意到的地方長期引用著不再使用的lua對象,導致這些對象無法被gc.
為了解決這個問題,google到一篇相似問題的文章,lua內(nèi)存泄漏查證.文章的大概思路就是:

1. 資源跟蹤,定位哪些資源泄漏
2. 引用檢索,查找泄漏的資源被哪個模塊引用

資源跟蹤

定義:將應(yīng)用中分配的lua對象添加到一個弱表中.執(zhí)行完整的gc后,還能從弱表中索引到的對象表示它還在別的地方被引用著,可能是正常的引用,也可能是一處內(nèi)存泄漏.
我使用了一個弱鍵表,該表以要跟蹤的lua對象為鍵,該對象的描述信息為值.其中的描述信息包含了對象描述和對象創(chuàng)建時間兩項.對象描述用于區(qū)別不同的跟蹤對象;創(chuàng)建時間則用來在打印弱表的時候判斷對象的存活時間是否合理.
我定義的接口是:function TraceMem(obj, description);

雖然機器人可以動態(tài)的加載無盡的模塊,但是幾乎所有的資源都是由幾個基礎(chǔ)模塊開始分配的,所以添加對象跟蹤相對比較簡單.經(jīng)過修改,運行,測試,從弱表中打印出來的數(shù)據(jù)發(fā)現(xiàn),機器人中有大量的移動包和移動相關(guān)的計時器對象沒有被gc掉,這些對象多數(shù)都已經(jīng)存活了100秒以上.場景中NPC都是僵尸,每個移動的時間應(yīng)該在5秒以下,所以可判定這些移動對象是泄漏.
問題的范圍縮小了,但還是看不出哪段代碼造成了泄漏?泄漏的對象在哪一個模塊中被引用?

引用檢索

定義:從某個節(jié)點開始搜索所有該節(jié)點引用的對象以及遞歸搜索子節(jié)點,找到要搜索的對象,打印出引用路徑.
最常見的可以從_G開始搜索.搜索到的每個table,取其key和value遞歸搜索;搜索到的每個函數(shù),取其upvalue遞歸搜索.至于是否需要搜索對象的環(huán)境表和metatable,以及全局registry表,則取決于具體需求.我因為用不上,就沒有搜索這一部分.
搜索的時候注意標記已經(jīng)搜索過的節(jié)點,避免重復(fù)搜索.最好能縮小搜索范圍,而不是從_G開始搜索,另外應(yīng)該能每次只搜索指定的部分引用而非全部,可以極大的縮短等待時間.搜索所有的引用其實相當耗時.
我定義的搜索接口是:function Search_r(obj, node, mark, result);

經(jīng)過引用檢索處理后,我看到了計時器模塊引用了那些泄漏的移動包和移動計時器對象,這些對象的創(chuàng)建時間和引用他們的激活時間居然是相同的,這導致了這些計時器對象不會再激活,同時也失去了激活后釋放的機會,造成了內(nèi)存泄漏.而根本原因,則是移動處理模塊在使用計時器的時候傳入了0超時參數(shù),因為僵尸走得太慢了.
到此,問題就算全部解決了.

PS:發(fā)現(xiàn)用html編輯blog非常不錯啊,比cppblog自帶的所見即所得編輯器好用多了,還可以用CSS和插入一些有趣的js.