Python多进程环境调用SimpleITK读取DICOM时出现bad allocation报错如何解决

• 核心诱因是系统内存不足：bad allocation是SimpleITK底层C++实现抛出的内存分配失败错误。多进程运行时每个进程都会独立占用内存存储加载的DICOM图像数据，进程数过多、单文件尺寸较大时会快速耗尽系统可用内存，导致后续排队的任务无法申请到足够内存触发报错。单进程运行时内存占用始终在系统承受阈值内，因此无异常。
• 资源泄漏叠加内存占用过高：如果batch_function处理完DICOM后没有主动释放SimpleITK图像对象的引用，进程内冗余对象会持续占用内存，任务运行到后期累计内存占用超标也会触发分配失败。
• 任务分片不均：如果分片逻辑不合理，导致最后几个分片集中了大量大尺寸DICOM任务，同时执行时的内存峰值超过系统可用内存上限。

1. 限制进程池并发数
   不要使用默认配置的multiprocessing.Pool()（默认会启动和CPU核心数相等的进程），根据机器可用内存、单DICOM平均大小手动设置并发数，比如16G内存、单DICOM平均大小1G的场景下，并发数控制在8以内：

# 示例：设置最大4进程并发
pool = multiprocessing.Pool(processes=4)

2. 主动释放冗余资源
   在batch_function中完成DICOM处理、拿到业务需要的结果后，主动删除SimpleITK图像对象并触发垃圾回收，降低进程内存占用：

import gc

# 原有读取逻辑
reader = sitk.ImageFileReader()
reader.SetImageIO("GDCMImageIO")
reader.SetFileName(dcm_path)
dcm = reader.Execute()

# 业务处理逻辑
process_result = your_custom_process(dcm)

# 处理完成后主动释放资源
del dcm
gc.collect()

3. 优化任务分片规则
   调整分片逻辑，保证每个分片的任务量、DICOM平均大小均匀，避免大尺寸文件集中在少数分片里。

4. 改用多线程实现（可选）
   如果你的工作流中IO等待占比高、计算占比低，可以替换为concurrent.futures.ThreadPoolExecutor实现多线程读取，线程间共享内存不会出现多进程内存重复占用的问题，且SimpleITK的读取操作线程安全，不会出现并发冲突。

内容的提问来源于stack exchange，提问作者Sys.Overdrive