Python 中的 C 扩展 - 名为 Py_DECREF 的 pyObject，引用为 0，但内存泄漏

Question

这是我的代码。

PyObject *dataPyParams = PyList_New(0);
for (int i = 0; i < figdata.dataSetList.size(); i++)
{
    PyObject *pyParams = PyList_New(0);
    for (int j = 0; j < figdata.dataSetList[i].size(); j++)
    {
        //std::cerr << figdata.dataSetList[i][j] << "data\n";
        auto temp = Py_BuildValue("f", figdata.dataSetList[i][j]);
        PyList_Append(pyParams,temp);
        Py_DECREF(temp);    
    }
    PyList_Append(dataPyParams, pyParams);
    Py_DECREF(pyParams);
    
}
Py_DECREF(dataPyParams);

我调用了 Py_DECREF(dataPyParams)，dataPyParams 引用为 0，但内存不是空闲的。 我尝试删除 PyList_Append(pyParams,temp)，这样可以释放内存。这很困扰我。

Answer 1

Python（和大多数语言）不直接满足操作系统的内存分配，也不会在发布时立即返回分配。它批量分配块内存，并通过对块进行分区来满足较小的请求。即使一个块中的所有内存都被“释放”了，它并不总是返回给操作系统，而是保留以备将来分配。

在这种情况下，您正在创建 float 和 list 对象，它们都有自己的“空闲列表”，因此释放不会实际上将它们返回给分配器，但是对于一个简单的已分配但未使用的对象堆栈，float 和 list 构造函数可以从中提取比向分配器请求更多内存更便宜。问题是，这也意味着这些元素所在的块根本无法返回给操作系统，因为它们的一部分仍然被分配，至少从分配器的角度来看是这样。您可以通过显式调用PyGC_Collect()（仅在a What's New doc 中记录的副作用）来清除这些空闲列表，这可能允许内存返回给操作系统，但同样不能保证。您可能还会want to disable pymalloc （以避免额外的小对象领域更不可能被交还给操作系统）。尽管如此，Python 完全有权无限期地保留大部分内存以满足未来的分配。

简而言之，这可能不是内存泄漏。您可以使用更高级的内存分析工具（如果不出意外，如果您在启动之前在环境中定义 PYTHONMALLOCSTATS=1，Python 本身会告诉您有关竞技场的使用情况），但任务管理器只能看到操作系统看到的内容，而不是内部Python 本身在原始、批量 OS 内存分配之上的内存管理。

在没有外部工具的情况下查看此是否泄漏的简单测试是多次运行此确切代码（包括清理）。如果每次运行时内存都以固定的大数量增长，那么是的，它可能是泄漏。但更有可能的是，您会发现第一次运行会消耗大量内存，但随后的运行会增加很少或没有内存使用（有些可能由于分配顺序和分配对齐问题而被使用，但会非常小），因为他们正在利用释放的内存（在用户空间，而不是操作系统），而不是向操作系统请求更多内存。