Python 3.12子解释器提供真正并行的独立解释器实例，各拥专属GIL与内存隔离，不共享对象，需通过channel通信，适合同构CPU密集任务，非I/O协同场景。
Python 3.12 的子解释器不是“实现真正的并行多线程”，而是提供**真正并行的独立解释器实例**——它不依赖 threading.Thread，也不共享 GIL，所以压根就不是多线程模型。
为什么 threading.Thread 在 CPU 密集场景下永远无法并行
所有 threading.Thread 实例都运行在同一个解释器里，共用一把全局 GIL。哪怕你启动 8 个线程跑 hashlib.sha256 或数值计算，CPython 仍强制它们轮流抢锁、串行执行。实测多核利用率常低于 20%，和单线程差别极小。
- 主线程调用
threading.Thread.start()后，OS 确实会调度多个原生线程，但 CPython 层面只允许一个持有 GIL -
time.sleep()、socket.recv()等 I/O 操作会主动释放 GIL，所以多线程对 I/O 密集型任务仍有价值 - 但只要代码持续执行 Python 字节码（比如循环累加、正则匹配、JSON 解析），GIL 就不会让出——这是设计使然，无法绕过
interpreters.create() 创建的是隔离运行时，不是线程
每个子解释器拥有自己的一套 PyInterpreterState、模块字典、异常状态和——最关键的——**专属 GIL**。它和主线程、其他子解释器之间默认内存隔离，不共享任何 Python 对象。
- 必须显式启用：启动 Python 时加
-X dev或设置环境变量PYTHONDEVMODE=1，否则import interpreters会失败 - 不能直接传函数闭包、lambda、自定义类实例给
run_async()，因为要走 pickle；连numpy.ndarray都得提前在目标解释器中导入模块 -
run_string()更轻量，适合执行纯字符串脚本（如"import math; print(math.sqrt(144))"），但无法传入外部定义的函数
channel_send() 是唯一合法通信方式，也是性能瓶颈点
子解释器之间没有共享内存，所有数据交换必须通过 interpreters.channel_send() 和 interpreters.channel_recv()，底层全程依赖 pickle/unpickle。
立即学习“Python免费学习笔记（深入）”；
- 传一个含 10 万个浮点数的
list，序列化+拷贝+反序列化耗时可能远超计算本身 - 避免在循环里高频调用
channel_send()；应聚合结果后一次性发送 - 嵌套深的 dict、带方法的对象、不可 pickle 的资源句柄（如文件对象）会直接报
TypeError: can't pickle ... - 大数组建议改用
memoryview+multiprocessing.shared_memory，而非靠 channel 搬运
真实并行的关键不在 API 调用，而在任务切分与数据流设计
子解释器不是把旧线程代码换个 run_async() 就能加速。你得接受：不能读对方的 globals()，不能修改同一份配置，不能共用缓存实例。
- 适合场景是“同构任务”：比如批量处理 1000 个 JSON 文件，每个子解释器分 200 个，各自解析、校验、生成报告，最后汇总
- 不适合场景是“状态协同”：比如一个子解释器做预处理，另一个接续训练模型，中间还要反复交换中间特征——通道开销会吃掉所有并发收益
- 调试困难：错误堆栈只显示子解释器内的执行路径，主线程捕获不到
ValueError细节，需手动包装异常并透传
最容易被忽略的一点：子解释器不是银弹，它解决的是「CPU 密集型任务在单进程内真并行」这个特定问题；如果你的任务本质是 I/O 等待或需要频繁跨单元交互，asyncio 或 multiprocessing 可能更稳、更易维护。
