如何在 Python 中显式地释放内存？

( del 可以成为你的朋友，因为当没有其他引用的时候，它将对象标记为可删除。现在，CPython解释器通常会保留这些内存供以后使用，所以你的操作系统可能不会看到 "释放 "的内存）。

也许你一开始就不会遇到任何内存问题，因为你的数据使用了一个更紧凑的结构。 因此，数字列表比标准的 array 模块或第三方的 numpy 模块所使用的格式更省内存。 你可以把顶点放在NumPy的3xN数组中，把三角形放在N元素数组中，从而节省内存。

你不能明确地释放内存。你需要做的是确保你不保留对对象的引用。然后它们将被垃圾回收，释放内存。

在你的情况下，当你需要大的列表时，你通常需要重新组织代码，通常使用生成器/迭代器来代替。这样一来，你根本不需要在内存中设置大的列表。

我在从文件中读取图形时遇到了类似的问题。处理过程包括计算一个200 000x200 000的浮动矩阵（一次一行），这不适合内存。试图用 gc.collect() 在计算之间释放内存，解决了与内存有关的问题，但它导致了性能问题。我不知道为什么，尽管使用的内存量保持不变，但每一次对 gc.collect() 的调用都比前一次多花一些时间。所以很快，垃圾收集就占用了大部分的计算时间。

为了解决内存和性能问题，我改用了我在某处读到的多线程技巧（很抱歉，我已经找不到相关帖子了）。之前我在一个大的 for 循环中读取文件的每一行，对其进行处理，并每隔一段时间就运行 gc.collect() 以释放内存空间。现在我调用一个函数，在一个新的线程中读取并处理文件的一个块。一旦线程结束，内存就会自动释放，不会出现奇怪的性能问题。

实际上，它是这样工作的。

from dask import delayed  # this module wraps the multithreading
def f(storage, index, chunk_size):  # the processing function
    # read the chunk of size chunk_size starting at index in the file
    # process it using data in storage if needed
    # append data needed for further computations  to storage 
    return storage
partial_result = delayed([])  # put into the delayed() the constructor for your data structure
# I personally use "delayed(nx.Graph())" since I am creating a networkx Graph
chunk_size = 100  # ideally you want this as big as possible while still enabling the computations to fit in memory
for index in range(0, len(file), chunk_size):
    # we indicates to dask that we will want to apply f to the parameters partial_result, index, chunk_size
    partial_result = delayed(f)(partial_result, index, chunk_size)
    # no computations are done yet !
    # dask will spawn a thread to run f(partial_result, index, chunk_size) once we call partial_result.compute()
    # passing the previous "partial_result" variable in the parameters assures a chunk will only be processed after the previous one is done
    # it also allows you to use the results of the processing of the previous chunks in the file if needed
# this launches all the computations
result = partial_result.compute()
# one thread is spawned for each "delayed" one at a time to compute its result
# dask then closes the tread, which solves the memory freeing issue
# the strange performance issue with gc.collect() is also avoided