8 一篇文章助力大家理解Python 代码中的垃圾回收机制.docxVIP

一篇文章助力大家理解Python 代码中的垃圾回收机制 先来看一段代码： 图1 这段代码读取tests/163/9.html这个文件里面的 HTML 代码，分别猎取 下面的全部标签内部的全部标签中的文本。说起来可能有点绕口，我举个例子。 你好 世界 分别猎取 标签和 标签下面的标签中的文本，也就是你好和世界。 但这段代码有个问题，就是对于嵌套结构的标签，会反复提取。例如： 你好 首先，猎取 标签下面的标签，猎取到的是你好所在的标签。但是，猎取 标签下面的标签时，猎取的仍旧是同一个标签。 这样一来，在上图代码里面第15-20行就会反复执行两次。 为了提高代码的运转效率，我们引入缓存，记录每一个标签的分析结果，假如发觉一个标签已经被分析了，就直接使用缓存的结果，避开反复分析。 于是，代码修改成下面这样： 图2 代码第18行的str(element)对应了这个节点的内存地址，如下图所示： 图3 这段代码看起来好像没有什么问题，但在实际提取数据的时候，发觉提取的结果不太正常。 薛定谔的 Element 为了调试这个问题，我对代码做了一下修改： 图4 可以看到，同一个 HTML 标签，之前缓存的结果竟然跟新提取的不一样。 于是，我想看看每次提取的时候，对应的 element 是哪个，但却发生了更诡异的事情，我们做一个看起来对代码不会有任何影响的改动： 图5 图4里面，我们直接把element_text_list缓存起来。图5里面，我们把[element_text_list, element]缓存起来，读取的时候，读取这个列表的下标为0的元素。也就是说，这个缓存的element我们根本不使用。 但惊异的事情就这样发生了，问题消逝了！在图4大量打印的同一个标签，缓存的数据跟提取的数据不全都！，在图5里面却一条都没有打印。这样修改以后，GNE 的提取的结果就正确了。 但为什么会发生这种事情呢？莫非说跟缓存的结果有关系？那么我们把列表里面的 element改成其他数据看看： 图6 仅仅是把element改成了数字1，Bug 又消灭了。 它好像晓得我在试图去观看它，当我尝试用代码去观看 element时，它就一切正常。当我不观看它时，它就会出问题。薛定谔的 element。 看不见的手 遇事不决，量子力学。这个问题跟量子力学实际上没有关系。导致这个诡异情况发生的缘由，是一个一直运转在 Python 里面，但是你经常忽视的机制——垃圾回收。 Python 会把不再使用的对象清理掉，从而释放内存。当我们执行一个 for 循环时： for element in element_list: a = element.xpath(//xxx) b = element.xpath(.//text()) c = 1 + 1 循环第一次执行的时候，生成第一个element对象，但是这个对象在循环其次次执行的时候就被新的element对象掩盖了。由于没有其他地方连续使用第一个 element 对象，它的引用计数归零，Python 的垃圾回收机制就会把它清理掉。它占用的内存空间也会被释放出来。 但假如换一种写法： cache = [] for element in element_list: a = element.xpath(//xxx) b = element.xpath(.//text()) c = 1 + 1 cache.append(element) 由于列表cache中包含了对每个 element 对象的引用，导致第一次循环生成的element对象的引用计数不为0，垃圾回收机制不会回收它，它一直占用了一块内存区域。这块区域不会被其他数据使用。那么每次循环，新的element对象都会新申请一块内存区域来存放数据，于是就等价于每一个不同的 element 节点对应了不同的内存地址。 在示例代码里面，大家留意element_flag = str(element)这一行，它的值类似于，这里的十六进制数字0x1087ba638对应了这个对象在内存里面的地址。 一开头，我有一个不正确的假设，我以为str(element)的值，对应的 HTML 里面的每个节点。同一个节点，多次执行，结果都一样，不同的节点，多次执行，结果都不一样。 但实际上这是不正确的。由于假如前一个节点的内存区域被垃圾回收了，那么这个区域会被重新安排，新来的节点可能碰巧会放到这个地方，这就导致两个不同的 标签，当你执行str(element)时，他们打印出来的结果都是相同的。但是实际上