是第三方库存在内存泄漏还是我对Python垃圾回收与内存管理理解有误？

你的Python垃圾回收认知是对的，问题出在你使用的Griddly第三方库存在底层内存泄漏。

原因说明 #

• Python的垃圾回收机制只能管理Python层面分配的对象内存，而Griddly的核心逻辑是C实现的，你通过clone()方法创建的环境，大部分内存是在C侧的堆上分配的，这部分内存不受Python GC管控，需要库本身的封装逻辑在Python wrapper对象被回收时同步释放底层资源。
• 你调用gc.collect()返回值为0，说明Python侧已经没有待回收的未引用对象，进一步验证了泄漏的内存都在底层C++侧，库的封装没有正确实现Python wrapper对象销毁时的底层资源释放逻辑，尤其是clone()方法生成的实例。

解决方案 #

1. 显式调用资源释放接口：大部分仿真环境的Python封装都会提供close()方法用来手动释放底层资源，你可以在每次使用完克隆的环境后，主动调用c_env.close()释放内存，修改后的循环逻辑参考：

for _ in range(10000):
    c_env = env.clone()
    # 处理克隆环境的逻辑
    c_env.close()

2. 验证泄漏范围：你可以测试不使用clone()，改为每次循环都重新创建GymWrapper实例，用完后调用close()，如果内存同样持续上涨，说明整个库的资源释放逻辑都有问题，如果只有clone()场景泄漏，就可以定位是clone()接口的实现bug。
3. 长期方案：如果显式调用close()后内存仍然不回落，说明这个库本身存在未修复的内存泄漏bug，你可以给库的开发团队提交issue反馈问题，或者调整业务逻辑避免高频调用clone()接口。

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