编写可导入的共享数组初始化/加载函数时遇崩溃与资源泄漏问题

这种差异的核心在于共享内存对象的生命周期管理、模块导入的上下文特性以及资源跟踪器的工作机制，具体拆解如下：

1. 模块导入时的对象引用残留 #

当init_shared_array和load_shared_array放在functions.py这类导入模块中时，函数内创建的SharedMemory对象可能被Python的模块缓存机制持有隐式引用。即使函数执行完毕，这些对象的引用计数没有降到0，导致SharedMemory的unlink()方法无法及时触发，共享内存资源没有被彻底清理，进而出现泄漏警告。

而直接把代码写在main.py主模块中时，对象的生命周期和主进程绑定更紧密，进程退出时Python会更彻底地回收所有主模块内的对象，共享内存资源能被正确清理，不会残留无效资源。

2. 资源跟踪器的上下文不匹配 #

Python的multiprocessing.shared_memory依赖内置的resource_tracker来监控和清理共享内存资源。导入模块（如functions.py）中的函数运行时，资源跟踪器的上下文和主进程的上下文存在差异，导致跟踪器无法准确记录共享内存对象的创建与销毁状态。

主模块内的代码运行在主进程的上下文里，resource_tracker能精准追踪每一个共享内存对象的生命周期，不会出现监控遗漏，自然也就不会触发资源泄漏警告和后续的访问错误。

3. 共享内存访问的资源冲突 #

当共享内存没有被正确清理时，后续调用load_shared_array尝试加载同名共享内存时，可能访问到已被释放或损坏的内存区域。这种非法内存访问直接触发操作系统的段错误（SIGSEGV），导致进程异常退出。而主模块中因为资源清理及时，不会出现这种冲突。

• 使用with语句管理SharedMemory对象的上下文，确保对象使用完毕后自动调用close()和unlink()：

  # functions.py 中修改后的示例
  from multiprocessing import shared_memory
  import numpy as np
  
  def init_shared_array(name, shape, dtype):
      shm = shared_memory.SharedMemory(create=True, size=np.prod(shape)*np.dtype(dtype).itemsize, name=name)
      arr = np.ndarray(shape, dtype=dtype, buffer=shm.buf)
      # 初始化数组逻辑
      return arr, shm
  
  def load_shared_array(name, shape, dtype):
      with shared_memory.SharedMemory(name=name) as shm:
          arr = np.ndarray(shape, dtype=dtype, buffer=shm.buf)
          return arr.copy()  # 返回数组副本，避免持有共享内存的引用
  

• 避免在导入模块中持有SharedMemory对象的长期引用，函数执行完毕后确保所有相关对象被显式销毁。
• 主进程中初始化共享内存后，要在所有依赖该资源的子进程退出后，再调用shm.unlink()完成最终清理。

内容的提问来源于stack exchange，提问作者L.B.