interpreters.create()创建的是带独立GIL的运行时实例而非线程，故能真并发跑满多核；threading.Thread仍受单GIL限制而串行执行。
interpreters.create() 创建的不是线程，而是带独立 GIL 的运行时实例——这才是它能跑满多核的根本原因。
子解释器 vs threading.Thread：GIL 不再是单点瓶颈
用 threading.Thread 启 4 个线程跑 hashlib.sha256，实际仍是串行：所有线程抢同一把全局 GIL；而用 interpreters.create() 启 4 个子解释器，每个自带独立 GIL，只要不共享对象，就能在不同 OS 线程里真并发。
主线程里的 threading.Thread 仍被主解释器的 GIL 锁死，无法突破单核限制；子解释器间默认内存隔离——不能直接读写彼此的 globals() 或模块变量，这既是限制，也是避免竞态的安全前提。
run_string() 和 run_async() 怎么选？看执行模型
interpreters.run_string() 是同步阻塞调用，适合短小、确定性脚本；run_async() 返回 Future 对象，更适合需要主线程继续干活、稍后取结果的场景。
-
run_string()内部会序列化传入的代码字符串和shared字典（只支持bytes、int、str等基础类型），开销低但灵活性差 -
run_async()支持传入可调用对象（如函数），但该函数必须能被pickle，且不能引用闭包外的不可序列化对象 - 若函数依赖第三方模块（如
numpy），需确保子解释器中已导入——run_string()可以显式写import numpy，run_async()则要提前在目标解释器中初始化环境
channel_send() 容易拖慢性能？因为全程 pickle
子解释器之间通信必须走 interpreters.channel_send()/interpreters.channel_recv()，而数据传递全程依赖 pickle/unpickle。哪怕只传一个 1MB 的 list，序列化+跨解释器拷贝+反序列化耗时可能超过计算本身。
- 不要在循环里高频调用
channel_send()；批量聚合后再传 - 避免传嵌套深、含自定义类或
lambda的结构——它们要么失败，要么触发复杂pickle协议，大幅拉长延迟 - 真正高效的数据传递方式是
SharedMemory + CIO（零拷贝引用传递），但仅限bytes、numpy.ndarray等支持 CIO 的类型
启用前提和常见静默失败点
子解释器不是装完 Python 3.12 就自动可用：
- 必须使用 CPython ≥ 3.12.0，且编译时启用了
--enable-subinterpreters（Linux/macOS 默认启用，Windows 官方构建暂未开启） - 验证支持状态：
python -c "import _interpreters; print(_interpreters.is_available())"必须返回True - 启动子解释器前需加
-X dev或设PYTHONDEVMODE=1，否则run_string()可能静默回退到主线程执行 - 子解释器中禁止调用
subprocess、避免动态import或eval()，否则极易崩溃或静默失败
立即学习“Python免费学习笔记（深入）”；
子解释器的并行能力高度依赖任务是否“纯解释器热点”——即不调用 C 扩展、不触发 I/O、不依赖外部库。一旦引入numpy 或 requests，GIL 行为可能重新介入，实际加速比会断崖下降。这点容易被忽略，但恰恰决定你写的并行逻辑到底有没有跑在多核上。 
