一、內(nèi)存泄漏

像Java程序一樣，雖然Python本身也有垃圾回收的功能，但是同樣也會(huì)產(chǎn)生內(nèi)存泄漏的問(wèn)題。
對(duì)于一個(gè)用 python 實(shí)現(xiàn)的，長(zhǎng)期運(yùn)行的后臺(tái)服務(wù)進(jìn)程來(lái)說(shuō)，如果內(nèi)存持續(xù)增長(zhǎng)，那么很可能是有了“內(nèi)存泄露”。

1、內(nèi)存泄露的原因

對(duì)于 python 這種支持垃圾回收的語(yǔ)言來(lái)說(shuō)，怎么還會(huì)有內(nèi)存泄露？ 概括來(lái)說(shuō)，有以下三種原因：

• 所用到的用 C 語(yǔ)言開(kāi)發(fā)的底層模塊中出現(xiàn)了內(nèi)存泄露。
• 代碼中用到了全局的 list、 dict 或其它容器，不停的往這些容器中插入對(duì)象，而忘記了在使用完之后進(jìn)行刪除回收
• 代碼中有“引用循環(huán)”，并且被循環(huán)引用的對(duì)象定義了__del__方法，就會(huì)發(fā)生內(nèi)存泄露。
  

為什么循環(huán)引用的對(duì)象定義了__del__方法后collect就不起作用了呢？

gc模塊最常使用的方法就是gc.collect()方法，使用collect方法對(duì)循環(huán)引用的對(duì)象進(jìn)行垃圾回收。
如果我們?cè)陬愔兄剌d了__del__方法。__del__方法定義了在用del語(yǔ)句刪除對(duì)象時(shí)除了釋放內(nèi)存空間以外的操作。
一般而言，在使用了del語(yǔ)句的時(shí)候解釋器首先會(huì)看要?jiǎng)h除對(duì)象的引用計(jì)數(shù)，如果為0，那么就釋放內(nèi)存并執(zhí)行del方法。
在這里，首先del語(yǔ)句出現(xiàn)時(shí)本身引用計(jì)數(shù)就不為0（因?yàn)橛醒h(huán)引用的存在），所以解釋器不釋放內(nèi)存；
再者，執(zhí)行collect方法時(shí)應(yīng)該會(huì)清除循環(huán)引用所產(chǎn)生的無(wú)效引用計(jì)數(shù)從而達(dá)到del的目的，對(duì)于這兩個(gè)循環(huán)引用對(duì)象而言，
python無(wú)法判斷調(diào)用它們的del方法時(shí)會(huì)不會(huì)要用到對(duì)方那個(gè)對(duì)象，比如在進(jìn)行b.del()時(shí)可能會(huì)用到b._a也就是a，如果在那之前a已經(jīng)被釋放，那么就徹底GG了。
為了避免這種情況，collect方法默認(rèn)不對(duì)重載了del方法的循環(huán)引用對(duì)象進(jìn)行回收，而它們倆的狀態(tài)也會(huì)從unreachable轉(zhuǎn)變?yōu)閡ncollectable。由于是uncollectable的，自然就不會(huì)被collect處理，所以就進(jìn)入了garbage列表。

2、內(nèi)存泄露的診斷思路

無(wú)論是哪種方式的內(nèi)存泄露，最終表現(xiàn)的形式都是某些 python 對(duì)象在不停的增長(zhǎng)；因此，首先是要找到這些異常的對(duì)象。

3、診斷步驟

用到的工具： gc 模塊和 objgraph 模塊

gc模塊 是Python的垃圾收集器模塊，gc使用標(biāo)記清除算法回收垃圾

objgraph 是一個(gè)用于診斷內(nèi)存問(wèn)題的工具

• 1、 在服務(wù)程序的循環(huán)邏輯中，選擇出一個(gè)診斷點(diǎn)
• 2、 在診斷點(diǎn)，插入如下診斷語(yǔ)句 　

import gc
import objgraph


### 強(qiáng)制進(jìn)行垃圾回收 
gc.collect() 

### 打印出對(duì)象數(shù)目最多的 50 個(gè)類型信息 
objgraph.show_most_common_types(limit=50) 

4、檢查統(tǒng)計(jì)信息，找到異常對(duì)象

運(yùn)行加入診斷語(yǔ)句的服務(wù)程序，并將打印到屏幕上的統(tǒng)計(jì)信息重定向到日志中。運(yùn)行一段時(shí)間后，就可以來(lái)分析日志，看看哪些對(duì)象在不停的增長(zhǎng)。

比如，排查結(jié)果可能是：
一個(gè)多線程程序，多個(gè)線程作為生產(chǎn)者，一個(gè)線程作為消費(fèi)者，通過(guò)將一個(gè) tuple 對(duì)象送入異步隊(duì)列進(jìn)行通信。
由于消費(fèi)者的處理速度跟不上生產(chǎn)者的速度，又沒(méi)有進(jìn)行同步， 導(dǎo)致異步隊(duì)列中的對(duì)象越來(lái)越多。

二、內(nèi)存溢出

1、內(nèi)存溢出原因

1. 內(nèi)存中加載的數(shù)據(jù)量過(guò)于龐大，如一次從數(shù)據(jù)庫(kù)取出過(guò)多數(shù)據(jù)
2. 集合類中有對(duì)對(duì)象的引用，使用完后未清空，產(chǎn)生了堆積，使得JVM不能回收
3. 代碼中存在死循環(huán)或循環(huán)產(chǎn)生過(guò)多重復(fù)的對(duì)象實(shí)體
4. 使用的第三方軟件中的BUG
5. 啟動(dòng)參數(shù)內(nèi)存值設(shè)定的過(guò)小

2、內(nèi)存溢出的解決方案

第一步，修改JVM啟動(dòng)參數(shù)，直接增加內(nèi)存(-Xms，-Xmx參數(shù)一定不要忘記加)

第二步，檢查錯(cuò)誤日志，查看“OutOfMemory”錯(cuò)誤前是否有其 它異?；蝈e(cuò)誤

第三步，對(duì)代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置

重點(diǎn)排查以下幾點(diǎn)：

1. 檢查對(duì)數(shù)據(jù)庫(kù)查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來(lái)說(shuō)，如果一次取十萬(wàn)條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個(gè)問(wèn)題比較隱蔽，在上線前，數(shù)據(jù)庫(kù)中數(shù)據(jù)較少，不容易出問(wèn)題，上線后，數(shù)據(jù)庫(kù)中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對(duì)于數(shù)據(jù)庫(kù)查詢盡量采用分頁(yè)的方式查詢。
2. 檢查代碼中是否有死循環(huán)或遞歸調(diào)用。
3. 檢查是否有大循環(huán)重復(fù)產(chǎn)生新對(duì)象實(shí)體。
4. 檢查L(zhǎng)ist、MAP等集合對(duì)象是否有使用完后，未清除的問(wèn)題。List、MAP等集合對(duì)象會(huì)始終存有對(duì)對(duì)象的引用，使得這些對(duì)象不能被GC回收。

第四步，使用內(nèi)存查看工具動(dòng)態(tài)查看內(nèi)存使用情況

三、內(nèi)存泄漏和內(nèi)存溢出的區(qū)別

內(nèi)存溢出是指向JVM申請(qǐng)內(nèi)存空間時(shí)沒(méi)有足夠的可用內(nèi)存了，就會(huì)拋出OOM即內(nèi)存溢出。

內(nèi)存泄漏是指，向JVM申請(qǐng)了一塊內(nèi)存空間，使用完后沒(méi)有釋放，由于沒(méi)有釋放，這塊內(nèi)存區(qū)域其他類加載的時(shí)候無(wú)法申請(qǐng)，

同時(shí)當(dāng)前類又沒(méi)有這塊內(nèi)存空間的內(nèi)存地址了也無(wú)法使用，相當(dāng)于丟了一塊內(nèi)存，這就是內(nèi)存泄漏。

值得注意的是內(nèi)存泄漏最終會(huì)導(dǎo)致內(nèi)存溢出，很好理解，內(nèi)存丟了很多最后當(dāng)然內(nèi)存不夠用了。

以上就是Python內(nèi)存泄漏和內(nèi)存溢出的解決方案的詳細(xì)內(nèi)容，更多關(guān)于Python內(nèi)存泄漏和內(nèi)存溢出的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論