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

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

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

import gc

gc.collect()

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

del my_array
del my_object
gc.collect()

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

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

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

不幸的是(取决于你的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.

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

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