向multiprocessing.context.Process传Lock/RLock时参数变为None如何解决

1. 多进程启动模式限制 #

如果你使用的是Windows系统，或是手动指定了spawn/forkserver作为多进程启动模式，进程创建时会重新导入所有模块，单独的原生multiprocessing.Lock/RLock不属于可跨进程序列化的对象，序列化过程会直接丢失状态。
你之前遇到的ForkingPickler报错是锁无法序列化的直接提示，后续代码调整后Pickler跳过了显式报错，直接将无法序列化的锁转为None，所以运行时只会拿到空值，不会抛出异常。

2. 原生锁的引用限制 #

普通原生锁仅能通过fork模式在亲缘进程间直接传递，你代码中的锁已经被绑定到context.flow._lock实例属性上，不属于顶层独立对象，序列化时Pickler无法正确处理这类绑定属性的锁引用，进一步加重了序列化失效问题。
而Queue能正常传递的原因是其内部已经做了跨进程序列化适配，底层锁和管道绑定，Pickler可以识别处理。

方案1：使用Manager生成可跨进程传递的锁（推荐，全平台兼容） #

这是适配成本最低的方案，仅需要修改锁的初始化逻辑，其余代码无需调整：

from multiprocessing import Manager, Lock, RLock
from multiprocessing.context import Process
from threading import Thread

# 新增Manager实例初始化，全局仅需初始化一次即可
manager = Manager()

use_processes = True

# ... 原有代码 ...

# 将原context.flow._lock替换为Manager生成的锁，需要RLock就调用manager.RLock()
context.flow._lock = manager.Lock()

thread_safe_context = context.make_thread_safe()
shared_lock: Lock = context.flow._lock
# 无特殊需求可以删掉这行：context.flow._lock = None，避免主进程后续用到锁时出问题

parallel_call = Thread
if use_processes:
    parallel_call = Process

p = parallel_call(
    target=worker_function,
    args=(thread_safe_self, shared_lock, thread_safe_context, self.use_savers, worker_arguments)
)
p.start()

Manager生成的锁是代理对象，原生支持Pickle序列化，可以正常跨进程传递，不会出现转为None的问题，唯一的缺点是性能略低于原生锁，绝大多数业务场景下无感知。

方案2：切换为fork启动模式（仅类Unix系统可用） #

如果你的运行环境是Linux/macOS，且主进程没有其他运行中的子线程，可以直接修改启动模式解决问题，无需修改锁相关逻辑：

import multiprocessing
# 放在所有多进程相关代码的最开头执行
multiprocessing.set_start_method('fork', force=True)

注意：如果主进程存在其他运行中的线程，fork模式可能会导致子进程出现死锁问题，生产环境慎用。

方案3：复用Queue内置锁（适配特定场景） #

如果你的锁是用来保护队列操作的，可以直接依赖multiprocessing.Queue的原生线程安全特性，无需额外传递独立锁，进一步简化代码。

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