看起来你已经做了不少基础的内存回收尝试，但问题依然存在，我来分享几个可能的排查方向：

1. 排查calculate_big_array()内部的隐藏引用 #

很多时候内存泄漏的根源不在外部的del或gc调用，而在创建数组的函数本身：

• 检查函数内是否把数组绑定到了全局变量、闭包变量或者某个长期存在的容器（比如模块级别的列表/字典）里，这些引用会让数组无法被GC回收。
• 如果使用了numpy、pandas这类数值库，有些数组可能存在共享内存视图或者底层C资源未正确释放的情况。可以在函数内部用sys.getrefcount(array)打印数组的引用计数，创建后和返回前看看数值是否合理——正常情况下，返回前引用数应该只有2左右（函数内的局部变量+返回值的临时引用）。
• 若函数里用到了第三方库（如PIL、OpenCV），部分对象需要显式调用释放方法（比如PIL.Image的close()），仅靠Python的自动回收是不够的。

2. 检查循环内的残留引用 #

你遍历的list里的x对象，会不会间接持有array1的引用？比如：

• 有没有在循环里把array1赋值给x的某个属性（如x.data = array1），但后续没有清空这个属性？
• 有没有把array1添加到某个全局/外部容器中，循环结束后也没移除？
  这些隐藏的引用链会让GC无法识别数组为垃圾对象。

3. 区分“内存泄漏”和“内存缓存” #

Python的内存分配器（pymalloc）会把释放的内存缓存起来，不会立刻还给操作系统，这可能造成内存泄漏的假象。你可以用tracemalloc工具精准追踪内存分配：

import tracemalloc

tracemalloc.start()

# 运行你的循环代码

snapshot = tracemalloc.take_snapshot()
top_stats = snapshot.statistics('lineno')

print("[Top 10 内存分配热点]")
for stat in top_stats[:10]:
    print(stat)

通过这个输出，你能看到哪一行代码分配的内存最多，直接定位到问题源头。

4. 优化数组的复用方式 #

你尝试把array1定义在循环外部，但如果calculate_big_array()每次返回新的数组对象，变量名不变只是指向了新对象，旧对象还是需要被回收。可以试试：

• 如果数组的形状固定，在循环外部初始化数组，然后在calculate_big_array()里直接修改数组内容（而不是返回新数组），这样避免频繁创建新对象。
• 每次循环结束后，除了del array1，再加一句array1 = None，确保变量不再持有任何引用。

5. 深入GC调试 #

你已经用了gc.set_debug(gc.DEBUG_LEAK)，但没看到未回收项，可能是因为GC确实回收了对象，但内存没还给系统。可以试试：

• 在循环中定期打印gc.get_objects()的数量，看看对象总数是否持续增长——如果总数稳定，那大概率是内存缓存而非泄漏。
• 用gc.get_referrers(array1)在del之前查看哪些对象还在引用这个数组，直接找到引用链。

内容的提问来源于stack exchange，提问作者Lara Larsen