【转】python的内存管理机制

http://developer.51cto.com/art/201007/213585.htm

内存管理，对于Python这样的动态语言，是至关重要的一部分，它在很大程度上甚至决定了Python的执行效率，因为在Python的运行中，会创建和销毁大量的对象，这些都涉及到内存的管理。

51CTO推荐阅读：对Python特色的详细介绍

小块空间的内存池

在Python中，许多时候申请的内存都是小块的内存，这些小块内存在申请后，很快又会被释放，由于这些内存的申请并不是为了创建对象，所以并没有对象一级的内存池机制。

 
Python内存池全景

这就意味着Python在运行期间会大量地执行malloc和free的操作，频繁地在用户态和核心态之间进行切换，这将严重影响Python的执行效率。为了加速Python的执行效率，Python引入了一个内存池机制，用于管理对小块内存的申请和释放。这也就是之前提到的Pymalloc机制。

在Python 2.5中，Python内部默认的小块内存与大块内存的分界点定在256个字节，这个分界点由前面我们看到的名为SMALL_REQUEST_THRESHOLD的符号控制。

也就是说，当申请的内存小于256字节时，PyObject_Malloc会在内存池中申请内存；当申请的内存大于256字节时，PyObject_Malloc的行为将蜕化为malloc的行为。当然，通过修改Python源代码，我们可以改变这个默认值，从而改变Python的默认内存管理行为。

在一个对象的引用计数减为0时，与该对象对应的析构函数就会被调用。

但是要特别注意的是，调用析构函数并不意味着最终一定会调用free释放内存空间，如果真是这样的话，那频繁地申请、释放内存空间会使 Python的执行效率大打折扣（更何况Python已经多年背负了人们对其执行效率的不满）。一般来说，Python中大量采用了内存对象池的技术，使用这种技术可以避免频繁地申请和释放内存空间。因此在析构时，通常都是将对象占用的空间归还到内存池中。

"这个问题就是:Python的arena从来不释放pool。这个问题为什么会引起类似于内存泄漏的现象呢。考虑这样一种情形，申请10*1024*1024个16字节的小内存，这就意味着必须使用160M的内存，由于Python没有默认将前面提到的限制内存池的WITH_MEMORY_LIMITS编译符号打开，所以Python会完全使用arena来满足你的需求，这都没有问题，关键的问题在于过了一段时间，你将所有这些16字节的内存都释放了，这些内存都回到arena的控制中，似乎没有问题。

但是问题恰恰就在这时出现了。因为arena始终不会释放它维护的pool集合，所以这160M的内存始终被Python占用，如果以后程序运行中再也不需要160M如此巨大的内存，这点内存岂不是就浪费了？"

Python内存管理规则：del的时候,把list的元素释放掉,把管理元素的大对象回收到py对象缓冲池里。

ps: 内核态和用户态的区别

当一个任务（进程）执行系统调用而陷入内核代码中执行时，我们就称进程处于内核运行态（或简称为内核态）。此时处理器处于特权级最高的（0级）内核代码中 执行。当进程处于内核态时，执行的内核代码会使用当前进程的内核栈。每个进程都有自己的内核栈。当进程在执行用户自己的代码时，则称其处于用户运行态（用 户态）。即此时处理器在特权级最低的（3级）用户代码中运行。当正在执行用户程序而突然被中断程序中断时，此时用户程序也可以象征性地称为处于进程的内核 态。因为中断处理程序将使用当前进程的内核栈。这与处于内核态的进程的状态有些类似。

内核态与用户态是操作系统的两种运行级别,跟
intel cpu没有必然的联系, intel
cpu提供Ring0-Ring3三种级别的运行模式，Ring0级别最高，Ring3最低。Linux使用了Ring3级别运行用户态，Ring0作为

内核态，没有使用Ring1和Ring2。Ring3状态不能访问Ring0的地址空间，包括代码和数据。Linux进程的4GB地址空间，3G-4G部

分大家是共享的，是内核态的地址空间，这里存放在整个内核的代码和所有的内核模块，以及内核所维护的数据。用户运行一个程序，该程序所创建的进程开始是运

行在用户态的，如果要执行文件操作，网络数据发送等操作，必须通过write，send等系统调用，这些系统调用会调用内核中的代码来完成操作，这时，必

须切换到Ring0，然后进入3GB-4GB中的内核地址空间去执行这些代码完成操作，完成后，切换回Ring3，回到用户态。这样，用户态的程序就不能
随意操作内核地址空间，具有一定的安全保护作用。