快捷導(dǎo)航

粗略分析Python中的內(nèi)存泄漏

更新時(shí)間：2015年04月23日 16:37:41 作者：C Wong

這篇文章主要介紹了粗略分析Python中的內(nèi)存泄漏,分析了包括在垃圾回收時(shí)產(chǎn)生等的原因,需要的朋友可以參考下

引子

之前一直盲目的認(rèn)為 Python 不會(huì)存在內(nèi)存泄露, 但是眼看著上線的項(xiàng)目隨著運(yùn)行時(shí)間的增長(zhǎng) 而越來(lái)越大的內(nèi)存占用, 我意識(shí)到我寫的程序在發(fā)生內(nèi)存泄露, 之前 debug 過(guò) logging 模塊導(dǎo)致的內(nèi)存泄露.

目前看來(lái), 還有別的地方引起的內(nèi)存泄露. 經(jīng)過(guò)一天的奮戰(zhàn), 終于找到了內(nèi)存泄露的地方, 目前項(xiàng)目跑了很長(zhǎng)時(shí)間, 在業(yè)務(wù)量較小的時(shí)候內(nèi)存還是能回到剛啟動(dòng)的時(shí)候的內(nèi)存占用.
什么情況下不用這么麻煩

如果你的程序只是跑一下就退出大可不必大費(fèi)周章的去查找是否有內(nèi)存泄露, 因?yàn)?Python 在退出時(shí) 會(huì)釋放它所分配的所有內(nèi)存, 如果你的程序需要連續(xù)跑很長(zhǎng)時(shí)間那么就要仔細(xì)的查找是否產(chǎn)生了內(nèi)存泄露.
場(chǎng)景

如何產(chǎn)生的內(nèi)存泄露呢, 項(xiàng)目是一個(gè) TCP server, 每當(dāng)有連接過(guò)來(lái)時(shí)都會(huì)創(chuàng)建一個(gè)連接實(shí)例來(lái)進(jìn)行管理, 每次斷開(kāi)時(shí)連接實(shí)例還被占用并沒(méi)有釋放. 沒(méi)有被釋放的原因肯定是因?yàn)橛心硞€(gè)地方對(duì)連接實(shí)例的引用沒(méi)有釋放, 所以隨著時(shí)間的推移, 連接創(chuàng)建分配內(nèi)存, 連接斷開(kāi)并沒(méi)有釋放掉內(nèi)存, 所以就會(huì)產(chǎn)生內(nèi)存泄露.
調(diào)試方法

由于不知道具體是哪里引起的內(nèi)存泄露, 所以要耐心的一點(diǎn)點(diǎn)調(diào)試.

由于知道了斷開(kāi)連接時(shí)沒(méi)有釋放, 所以我就不停的模擬創(chuàng)建連接然后發(fā)送一些包后斷開(kāi)連接, 然后通過(guò)下面一行 shell 來(lái)觀察內(nèi)存占用情況:

PID=50662;while true; do; ps aux | grep $PID | grep -v grep | awk '{print $5" "$6}' >> t; sleep 1; done

如果在增長(zhǎng)了一定的量后保持住就說(shuō)明已經(jīng)沒(méi)有產(chǎn)生泄露.

同時(shí)可以在對(duì)象該釋放的時(shí)候查看對(duì)象的引用計(jì)數(shù), 通過(guò) sys.getrefcount(obj). 如果引用計(jì)數(shù)變?yōu)榱?2 則說(shuō)明該對(duì)象在跳出命名空間后就會(huì)被正確回收.
產(chǎn)生原因

項(xiàng)目中兩種情況導(dǎo)致對(duì)象沒(méi)有被正確回收:

被退出才回收的對(duì)象引用
交叉引用

被退出才回收的對(duì)象引用

為了追蹤連接所以把連接對(duì)象同時(shí)放在一個(gè)列表里, 而這個(gè)列表只有在程序退出時(shí)才會(huì)被回收, 如果不正確處理, 那么分配的對(duì)象將也會(huì)只在程序退出時(shí)才會(huì)被回收.

全局變量和類變量都只會(huì)在程序退出的時(shí)候才會(huì)被回收:

_CONNECTIONS = []

# ...
class Connection(object):
 def __init__(self, sock, address)
  pass

def server_loop():
 # ...
 sock, address = server_sock.accept()
 connection = Connection(sock, address)
 _CONNECTIONS.append(connection)
 # ...
 sock.close()

上面把所有建立的連接都放在全局變量 _CONNECTIONS 里, 如果在關(guān)閉的時(shí)候不從這個(gè)列表里取出(減少引用)則 connection 對(duì)象就不會(huì)被回收, 則每建立一次連接就會(huì)有個(gè)連接對(duì)象和連接對(duì)象引用的對(duì)象不會(huì)被回收.

如果把對(duì)象放在一個(gè)類屬性里也是一樣的, 因?yàn)轭悓?duì)象在程序一開(kāi)始就分配, 并在程序退出時(shí)才被回收.

解決辦法就是在退出時(shí)從列表(或其他對(duì)象)里解除對(duì)對(duì)象的引用(刪除)

_CONNECTIONS = []

# ...
class Connection(object):
 def __init__(self, sock, address)
  pass

def server_loop():
 # ...
 sock, address = server_sock.accept()
 connection = Connection(sock, address)
 _CONNECTIONS.append(connection)
 try:
  # ...
  sock.close()
 finally:
  _CONNECTIONS.remove(connection) # XXX

交叉引用

有時(shí)候我們?yōu)閷?duì)象分配一個(gè)實(shí)例屬性時(shí)需要將自己本身賦值給實(shí)例屬性, 作為實(shí)例屬性的實(shí)例屬性, 說(shuō)著很拗口, 看一下代碼:

class ConnectionHandler(object):
 def __init__(self, connection):
  self._conn = connection


class Connection(object):
 def __init__(self, sock, address)
  self._conn_handler = ConnectionHandler(self) # XXX

上面的代碼就會(huì)產(chǎn)生交叉引用, 交叉引用會(huì)讓解釋器困惑, 從而之后只能靠2代和3代回收, 這個(gè)過(guò)程可能會(huì)很慢.

解決這種問(wèn)題的方法就是使用弱引用

import weakref

class ConnectionHandler(object):
 def __init__(self, connection):
  self._conn = connection


class Connection(object):
 def __init__(self, sock, address)
  self._conn_handler = ConnectionHandler(weakref.proxy(self)) # XXX

您可能感興趣的文章: