这一点最近刺痛了我。我通过从代码中删除所有 numpy 数组与列表的比较来解决它。但是为什么垃圾收集器会错过收集它呢?
运行它,看着它吃掉你的记忆:
import numpy as np
r = np.random.rand(2)
l = []
while True:
r == l
在 64 位 Ubuntu 10.04、virtualenv 1.7.2、Python 2.7.3、Numpy 1.6.2 上运行
这一点最近刺痛了我。我通过从代码中删除所有 numpy 数组与列表的比较来解决它。但是为什么垃圾收集器会错过收集它呢?
运行它,看着它吃掉你的记忆:
import numpy as np
r = np.random.rand(2)
l = []
while True:
r == l
在 64 位 Ubuntu 10.04、virtualenv 1.7.2、Python 2.7.3、Numpy 1.6.2 上运行
以防万一有人偶然发现这个并想知道...
@Dugal 是的,我相信这是当前 numpy 版本(2012 年 9 月)中的内存泄漏,发生在引发一些异常时(参见this和this)。为什么添加gc
@BiRico 确实“修复”的调用对我来说似乎很奇怪,尽管它必须在看起来之后立即完成?如果有人知道异常处理和垃圾收集 CPython 内部,我会感兴趣,这可能与 python 垃圾收集回溯的方式很奇怪。
解决方法:这与列表没有直接关系,但例如大多数广播异常(空列表不适合数组大小,空数组会导致相同的泄漏。请注意,内部准备了一个永远不会出现的异常)。因此,作为一种解决方法,您可能应该首先检查形状是否正确(如果您经常这样做,否则我不会担心,如果我做对了,这只会泄漏一个小字符串)。
已修复:此问题将在 numpy 1.7 中修复。
抱歉,我无法给出更完整的答案,但这似乎与垃圾收集有关。我能够在 Redhat 5.8 上使用 python 2.7.2、numpy 1.6.1 重新创建这个问题。但是,当我尝试以下操作时,内存使用恢复正常。
import gc
import numpy as np
r = np.random.rand(2)
l = []
while True:
r == l
gc.collect()