RasterModelGrid实例化内存累积问题原因及排查方案

从对照测试结果看，直接实例化父类DualUniformRectilinearGraph时，del操作后内存可以正常释放，但实例化子类RasterModelGrid时内存持续增长，核心原因是**RasterModelGrid实例在初始化后被某个强引用持有，导致引用计数始终不为0，垃圾回收机制无法释放实例挂载的大体积numpy数组，每轮循环创建的新网格对象都会叠加占用内存**。
结合给出的初始化代码，最高概率的几个触发点：

• 多继承引入的外部持有：RasterModelGrid同时继承了DiagonalsMixIn、ModelGrid、RasterModelGridPlotter三个额外父类，其中绘图类RasterModelGridPlotter大概率会在初始化时把实例绑定到matplotlib的全局画布管理器、事件回调列表中，这类全局容器会长期持有实例引用，导致实例无法被回收。
• 类级/全局缓存泄漏：ModelGrid基类或者DiagonalsMixIn中可能存在类级别的缓存字典/列表，会自动注册新创建的网格实例，且没有淘汰机制，所有创建过的实例都会被永久持有。
• 初始化逻辑的隐式绑定：代码中调用的set_closed_boundaries_at_grid_edges等方法，可能会在内部把实例的属性、方法绑定到全局静态变量、Cython扩展层的全局结构中，形成隐式引用。
• 多继承初始化顺序问题：当前用显式调用父类__init__的方式而非super()，在钻石继承场景下可能出现某个父类重复初始化、或者初始化逻辑遗漏释放标记的问题，这个概率相对低。
  tracemalloc中看到的大内存块都是网格结构生成的numpy数组，这些数组本身都是实例的属性，只要实例不被回收，这些数组就会一直驻留内存，和观察到的每轮循环新增~280MiB内存占用的现象完全匹配。

不需要通读全量源码，按下面的顺序二分排查，最快十几分钟就能定位根因：

• 第一步：先确认泄漏类型
  在每次del grido之后手动调用gc.collect()强制触发全量垃圾回收，再采集内存快照。如果强制回收后内存可以正常释放，说明是循环引用导致的回收延迟（重点排查有没有对象互相引用且定义了__del__方法的场景）；如果强制回收后内存还是不释放，说明存在全局/静态对象持有的强引用，继续往下走。
• 第二步：二分裁剪初始化逻辑缩小范围
  写一个临时测试类，逐段注释RasterModelGrid初始化中的逻辑，每改一次跑一次循环测内存：
  • 先临时去掉DiagonalsMixIn、RasterModelGridPlotter两个父类，只保留DualUniformRectilinearGraph和ModelGrid的继承，如果泄漏消失，问题就在去掉的两个父类里
  • 逐段注释__init__里的逻辑：先注释掉ModelGrid.__init__调用，再注释掉_node_status赋值、边界条件设置、looped属性初始化，每注释一段测一次，哪段注释完内存可以正常释放，问题就在哪段代码里。
• 第三步：直接查实例的引用链
  用Python内置的gc模块直接追踪是谁持有了实例的引用，这是最直接的定位方法，示例代码：

  import gc
  gc.collect()
  grido = RasterModelGrid((3000, 3000), 10)
  # 记录当前引用数
  print("初始化完成后引用数：", len(gc.get_referrers(grido)))
  del grido
  gc.collect()
  # 遍历所有还在引用grido的对象
  for ref in gc.get_referrers(grido):
      print("持有引用的对象类型：", type(ref))
      # 如果是字典/列表，打印它所属的对象
      if isinstance(ref, dict):
          for k, v in globals().items():
              if v is ref:
                  print("属于全局变量：", k)
          for obj in gc.get_referrers(ref):
              if hasattr(obj, '__class__'):
                  print("所属类：", obj.__class__)
  

  跑完直接就能看到是全局缓存、matplotlib管理器、还是类属性持有了实例，顺着找就能看到具体的持有位置。
• 第四步：排查C扩展层泄漏
  如果上面Python层没找到持有引用的对象，再去查调用的Cython扩展（比如StructuredQuadLayoutCython），看有没有在C层静态持有numpy数组或者实例指针、没有正确做引用计数递减的逻辑。不过从父类实例化正常的对照结果看，这个概率极低。
• 第五步：排查全局缓存逻辑
  搜下代码里有没有用lru_cache、全局字典/列表做网格属性缓存的地方，如果缓存key直接绑定了网格实例，且缓存没有大小限制，就会导致所有创建过的实例都被缓存强引用，无法回收。

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