Python多进程后文件写入异常：两种写法的差异排查

直接说核心结论：写法1中输出文件的句柄被多进程子进程意外继承并关闭，导致主进程后续写入失效；写法2因为在多进程任务完成后才打开输出文件，完全避开了句柄继承的冲突。

具体差异拆解 #

1. 文件句柄的跨进程继承特性

在Unix-like系统中（Python的multiprocessing.Pool默认用fork启动子进程），子进程会完全继承主进程打开的所有文件描述符。写法1里，output_file的句柄是在主进程的with块中打开的，当你创建mp.Pool并启动子进程时，这些子进程都会拿到这个输出文件的句柄副本。

虽然你的子进程代码（call_api）里没有显式操作这个文件，但子进程退出时，系统会自动清理它持有的所有文件描述符——包括这个继承来的输出文件句柄。当子进程关闭这个句柄后，主进程里的原句柄就会变成无效状态，此时主进程再调用of.write()时，看起来没有报错，但实际上写入操作已经失败（数据可能被丢弃，或者句柄已被内核回收）。

2. 为什么pool.close()和pool.join()没用？

pool.close()只是禁止向进程池提交新任务，pool.join()是等待所有子进程执行完毕，但这两个操作都无法改变子进程已经继承了文件句柄的事实。子进程在退出时依然会清理自己持有的文件描述符，哪怕你已经调用了join，主进程的文件句柄已经被子进程关闭，后续写入自然失效。

3. 写法2的安全逻辑

写法2把输出文件的打开操作放在了多进程任务完成之后：主进程先完成所有批量处理，等所有子进程都退出、资源清理完毕后，才打开输出文件写入耗时。此时输出文件的句柄完全由主进程持有，没有任何子进程会接触到它，所以写入操作可以正常执行。

验证与修复建议 #

• 验证方法：可以在写法1的of.write()之前加一行print(of.closed)，你会发现输出是True——说明文件句柄已经被关闭了。
• 修复方案：
  • 优先采用写法2的模式，在多进程任务完全结束后再打开输出文件，这是最稳妥的方式；
  • 如果必须提前打开输出文件，可以在打开后设置文件描述符不可继承：

    with open('input_file', 'r') as input_file, open('output_file', 'a') as of:
        # 禁止子进程继承输出文件句柄
        import os
        os.set_inheritable(of.fileno(), False)
        # 后续批量处理逻辑不变
        batch = read_next_batch_of_lines()
        start_time = time.time()
        call_api_for_each_item_in_batch(batch)
        end_time = time.time()
        of.write('{}\n'.format(end_time-start_time))
    

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