python开发的程序内存越来越大_遇到个python进程占用内存太多的问题 | 盛大创新院团队博客 | 数据，更懂人心...

在几个前辈的影响下，也开始用起了python，上手较快，并且觉得内存回收这些个烦心事自己也不用过问，自有解释器来完成。直到开始抓取某吧的帖子时才遇到问题。

抓取的思路很简单：获取某个分类下的所有的吧； 获取某个吧下的所有帖子；获取某个帖子的所有回复页。并且上面的每个步骤都是一个单独的接口实现。但是程序跑起来总是被莫名杀掉，并且dmesg查看会有“out of memory”的信息，应该是进程占用内存太大，被系统强制停掉。想着觉得不可思议，估算下，一个帖子只存储link和anchor，平均算上256byte，一个吧最多500w帖子，才用1G+多些，怎么会在一台16G的机器上down掉的呢(该机器虽然有其他程序，但每次进程退出时至少都占用了7G+).

于是开始找了些python的内存检测相关的工具和说明的页面看了看。

工具方面：

1、尝试valgrind检查，”确实看到很多xx are still reachable”的日志，而且这个xx数字越往后越大，囧。但是这些trace都是python解释器调用底层接口，也无法看懂(有个网页说到python2.x解释器可能存在内存泄露但还是先从自己程序找问题)。

2、cprofile分析：输出文件里有各个接口的调用次数和平均处理时间之类的，更像是解决性能的辅助工具。

3、尝试用gc模块的gc.collect接口进行强制的内存回收，没有效果。

4、尝试meliae：在上面的每次循环处理之后打印各个对象的占用情况，发现最多的对象都是beautifulsoup的Navigating占用了快80%的内存，于是在每次soup的find的object使用完后都强制del，仍然没有效果(感觉这个检测结果有点误导性)。

这个时候回头再仔细想了想之前的帖子里讲到的python的内存虽然会自动回收，但是回收完之后的内存并不是还给系统，而仍然是作为python的内存池。所以最根本的解决方法就是如何尽量少的让python从系统申请内存和复用自身的内存池资源。于是将上面的抓取流程稍微改动一下，每次并不是获取完一个吧的所有帖子，而且每次只获取一页的帖子，重新运行，便发现python的内存占用始终维持在0.2%左右了。

某种程序上来说，这种内存管理方式并没有能解释得通为何第一种写法会占用越来越大的内存；不过后来的解决方法却可以作为以后写python脚本时内存考虑的一个指导点。同时几种工具使用一遍，也是个不错的经历。更高追求的同学还可以关注下如何高效地释放内存的方式，我还没有尝试过。