全球關注：如何玩轉Lua內存回收？Lua的內存監測和回收

來源：CSDN 時間：2023-01-03 07:41:59

Lua內存是自動收集的,?這點跟Java類似,?不被任何對象或全局變量引用的數據，將被首先標記為回收,不需要開發者做任何事情.但是，正如Java也會有內存泄露一樣, Lua也會有,?只不過,跟C++的不同，它是由于代碼執行所裝載的資源，并沒有被徹底銷毀而導致,其中，最臭名昭著的就是不小心把局部變量聲明成了全局變量(忘了加local修飾符)。?類似這樣造成的內存泄露,?跟任何其他語言的內存泄露一樣，容易產生，卻難以察覺,?給開發的應用帶來潛在的很大隱患.

那么,?有沒有一些有效的解決辦法,?來解決這個這個隱患呢,?答案就是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被誤聲明為全局:

結果:

也就是說,內存也在25906K,跟test1幾乎是相等,?好了，現在再調用回收(mem)函數,產生結果如下 ?為了保證函數回收被執行，這次，總共調用了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")）進行顯式回收。

大小: 2.7 KB 大小: 6.3 KB 大小: 4.6 KB 大小: 5.7 KB 大小: 9.2 KB 大小: 2.3 KB 大小: 2.3 KB

責任編輯：

標簽：

上一篇：什么是Config？Config的詳情介紹
下一篇：最后一頁