类装饰器配合multiprocessing调用类方法报PicklingError求解

该PicklingError由三个逻辑问题共同触发：

• 类装饰器返回值错误：原autorun装饰器最终返回类实例而非类本身，导致__main__模块下的Runner变量被替换为实例对象。当多进程序列化绑定方法self._check_db时，需要先查找实例所属的Runner类，此时无法在__main__模块中找到合法的类定义，直接触发序列化失败。
• 执行时机错误：装饰器在类定义流程中就立即实例化并调用run()，此时类还未被绑定到__main__模块的命名空间（类装饰器的返回值才会被赋值给类名变量），即使临时修复返回值，该时机问题也会导致类查找失败。
• 隐藏递归bug：原写法在macOS/Python3.8+默认的spawn多进程启动模式下，子进程会重新导入主脚本，重复触发装饰器的run()逻辑，会导致无限递归创建子进程。

无需修改_check_db的类方法写法，也无需引入第三方序列化库，仅修正autorun装饰器逻辑即可，全部基于Python标准库实现：

1. 装饰器始终返回原始类，保证类在模块命名空间中可被正常序列化查找。
2. 增加环境变量标记，避免spawn子进程导入主模块时递归启动运行逻辑。
3. 通过0延时定时器将实例化、run()调用的逻辑调度到类完成命名空间绑定之后执行，解决类查找的时机问题。

修正后的runner_base.py代码如下：

from abc import ABC, abstractmethod
from multiprocessing import Process
import os
from threading import Timer


_AUTORUN_FLAG = "_RUNNER_AUTORUN_STARTED"


class RunnerBaseClass(ABC):
    @abstractmethod
    def _train(self) -> None:
        ...

    def _check_db(self):
        print("Checking DB")

    def run(self) -> None:
        db_check_process = Process(target=self._check_db)
        db_check_process.start()
        self._train()
        db_check_process.join()


def autorun(env_name: str):
    def class_decorator(class_):
        # 仅在直接运行主脚本、且未触发过自动运行时执行逻辑
        if env_name == "__main__" and _AUTORUN_FLAG not in os.environ:
            # 打环境标记，子进程会继承该标记，避免递归启动
            os.environ[_AUTORUN_FLAG] = "1"

            def _start_run():
                instance = class_()
                instance.run()

            # 0延时调度，等当前类完成主模块命名空间绑定后再执行
            Timer(0, _start_run).start()

        # 必须返回原始类，保证类可被正常序列化查找
        return class_
    return class_decorator

业务层run.py无需任何修改，保持原有写法即可：

from runner_base import RunnerBaseClass, autorun

@autorun(__name__)
class Runner(RunnerBaseClass):
    def _train(self) -> None:
       print("Training")

直接运行python run.py即可正常输出Checking DB和Training，无Pickle报错，也不会出现递归创建进程的问题，同时_check_db作为类方法可以正常访问实例的所有属性、配置和通信对象。

注：Timer创建的是非守护线程，Python解释器会等待该线程执行完成再退出，不会出现主进程提前退出、训练逻辑被截断的问题。

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