使用Pool.map()处理Pandas DataFrame时内存占用剧增的原因

这是个很常见的Pandas多进程内存坑，我来帮你拆解几个核心原因，再给你对应的解决思路：

1. 写时复制（Copy-on-Write）机制的“意外”触发 #

Unix-like系统下Python多进程默认用fork创建子进程，理论上会通过写时复制共享主进程的内存——只有当子进程修改内存内容时，才会真正复制数据。但Pandas的DataFrame底层依赖NumPy数组，而NumPy的内存管理和Python的引用计数机制结合时，很容易触发意外的复制：

• 如果你主进程里的大my_df没有被及时释放，每个子进程都会继承对这个大DataFrame的内存引用。哪怕你只传小DF给子进程，子进程的内存空间里依然会保留大DF的“影子”，一旦在处理过程中触发任何会修改内存的操作（哪怕是读取某些特殊列），就会触发全量复制，直接把子进程的内存拉到和主进程差不多的水平。

2. Pickle序列化的额外内存开销 #

Pool.map()在传递参数时，会用pickle把小DataFrame序列化后传给子进程，子进程再反序列化还原。但Pandas对象的pickle反序列化过程会产生额外的内存开销：

• 反序列化后的DataFrame在内存中的实际占用往往比原对象大，尤其是当你的数据包含object类型列（比如字符串）时，pickle会重新分配内存存储这些对象，再加上子进程本身的Python解释器、Pandas库等基础内存占用，叠加起来就很容易达到2GB/进程的水平。

3. 子进程复用导致的内存累积 #

multiprocessing.Pool的子进程是复用的——完成一个任务后不会立即销毁，而是继续处理下一个任务。如果你的自定义函数里没有及时清理中间变量，或者Python的垃圾回收没有及时回收废弃对象，前一次任务的内存占用会保留在子进程中，导致内存持续升高。

对应的解决思路 #

• 及时释放主进程的大DataFrame：拆分完小DF列表后，立刻删除主进程的大DF并强制垃圾回收，避免子进程继承不必要的内存：

  import gc
  
  def main():
      my_df = pd.read_table("my_file.txt", sep="\t")
      # 拆分小DataFrame到列表的逻辑
      small_dfs = split_into_small_dfs(my_df)
      # 关键：删除大DF并回收内存
      del my_df
      gc.collect()
      # 再启动多进程处理
      with Pool(processes=4) as pool:
          pool.map(your_custom_func, small_dfs)
  

• 优化数据传递方式：如果可以，改用dask.dataframe这类专为大数据并行设计的框架，它会自动处理内存分片和进程间数据传递，避免手动拆分的内存问题；或者用multiprocessing.Array共享内存（适合简单数据类型），减少pickle的开销。

• 清理子进程内的内存：在自定义函数末尾显式删除中间变量并触发垃圾回收：

  def your_custom_func(small_df):
      # 处理逻辑
      result = process_df(small_df)
      # 清理内存
      del small_df
      gc.collect()
      return result
  

• 控制进程数量：不要盲目开过多进程，一般建议进程数等于CPU核心数（比如os.cpu_count()），过多的进程会加剧内存竞争，反而让内存占用飙升。

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