Python是垃圾回收的，所以如果你减少列表的大小，它会回收内存。你也可以使用"del"语句完全摆脱一个变量:

biglist = [blah,blah,blah]
#...
del biglist

del语句可能有用，但IIRC不能保证释放内存。医生来了…这里有一个不发布的原因。

我听说有人在Linux和unix类型的系统上使用python进程来做一些工作，得到结果，然后终止它。

本文介绍了Python垃圾收集器，但我认为缺乏内存控制是托管内存的缺点

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

在您的情况下，当您需要大型列表时，通常需要重新组织代码，通常使用生成器/迭代器代替。这样你就不需要在内存中存储大的列表。

根据Python官方文档，你可以显式调用gc.collect()来释放未引用的内存。例子:

import gc

gc.collect()

你应该在使用del标记你想丢弃的东西后这样做:

del my_array
del my_object
gc.collect()

不幸的是(取决于你的Python版本和发行版)，某些类型的对象使用“自由列表”，这是一种简洁的局部优化，但可能会导致内存碎片，特别是通过将越来越多的内存“指定”给特定类型的对象，从而无法用于“普通基金”。

The only really reliable way to ensure that a large but temporary use of memory DOES return all resources to the system when it's done, is to have that use happen in a subprocess, which does the memory-hungry work then terminates. Under such conditions, the operating system WILL do its job, and gladly recycle all the resources the subprocess may have gobbled up. Fortunately, the multiprocessing module makes this kind of operation (which used to be rather a pain) not too bad in modern versions of Python.

在您的用例中，似乎子进程积累一些结果并确保这些结果对主进程可用的最佳方法是使用半临时文件(我所说的半临时是指，不是那种关闭时自动消失的文件，而是在您全部使用完后显式删除的普通文件)。

如果您不关心顶点重用，您可以有两个输出文件——一个用于顶点，一个用于三角形。完成后，将三角形文件附加到顶点文件。

其他人已经发布了一些方法，您可以“哄骗”Python解释器释放内存(或以其他方式避免内存问题)。你应该先尝试他们的想法。但是，我觉得有必要直接回答你的问题。

实际上没有任何方法可以直接告诉Python释放内存。事实是，如果你想要这么低的控制级别，你将不得不用C或c++写一个扩展。

也就是说，有一些工具可以帮助解决这个问题:

cython 痛饮 提高python

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

通过对数据使用更紧凑的结构，也许一开始就不会遇到内存问题。 因此，与标准数组模块或第三方numpy模块使用的格式相比，数字列表的内存效率要低得多。您可以通过将顶点放在NumPy 3xN数组中，将三角形放在n元素数组中来节省内存。

I had a similar problem in reading a graph from a file. The processing included the computation of a 200 000x200 000 float matrix (one line at a time) that did not fit into memory. Trying to free the memory between computations using gc.collect() fixed the memory-related aspect of the problem but it resulted in performance issues: I don't know why but even though the amount of used memory remained constant, each new call to gc.collect() took some more time than the previous one. So quite quickly the garbage collecting took most of the computation time.

为了解决内存和性能问题，我改用了我曾经在某个地方读过的多线程技巧(对不起，我再也找不到相关的帖子了)。之前，我在一个大的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

正如其他答案已经说过的，Python可以避免释放内存给操作系统，即使Python代码不再使用内存(因此gc.collect()不会释放任何东西)，特别是在长时间运行的程序中。无论如何，如果您在Linux上，您可以尝试通过直接调用libc函数malloc_trim(手册页)来释放内存。 喜欢的东西:

import ctypes
libc = ctypes.CDLL("libc.so.6")
libc.malloc_trim(0)