Python 3.12 的 per-interpreter GIL 并未解除 threading 模块的 GIL 限制，而是为子解释器提供独立 GIL 和内存隔离；它不兼容多线程共享状态，需用字符串传代码、显式创建子解释器，并依赖 queue 或共享内存交换数据。
它不能直接解决你代码里 threading 模块的多线程痛点——Python 3.12 的 per-interpreter GIL 不是给现有线程用的，而是为子解释器（subinterpreters）设计的隔离机制。
per-interpreter GIL 不等于 threading.Thread 的 GIL 放开
很多人看到“GIL 被解决了”就立刻改写 ThreadPoolExecutor，结果发现 CPU 密集任务依然只跑满一个核。这是因为：
-
threading模块的所有线程仍共享主解释器的单个 GIL，per-interpreter GIL对它们完全透明 - 子解释器（通过
_interpreters或未来interpreters模块创建）才各自拥有独立 GIL 和独立内存空间 - 你不能在子解释器里直接访问主线程的
list、dict或任何 Python 对象——它们之间默认不共享状态
真正能并发的代码必须显式创建子解释器
想利用这个特性，你得放弃“多线程”思维，转而用子解释器做隔离执行单元。最小可行示例：
import _interpreters
<h1>创建两个独立解释器</h1><p>interp_a = _interpreters.create()
interp_b = _interpreters.create()</p><h1>向每个解释器传入独立代码（字符串形式）</h1><p>interp_a.run("import time; time.sleep(1); print('done in A')")
interp_b.run("import time; time.sleep(1); print('done in B')")</p><h1>注意：这两段代码是真正并行的（如果底层线程调度允许）</h1><h1>但你无法用 interp_a 访问 interp_b 的变量，也不能传入函数对象</h1><p></p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill9965" title="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill9965" title="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac" class="overflowclass">macOS UI 自动化技能包 —— 用 Python 控制你的 Mac</a>
<p class="overflowclass">让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript
系统要求
macOS 14+ (Sonoma)
Python 3.9+
需要开启：辅助功能 + 屏幕录制权限</p>
</div>
<a rel="nofollow" href="/xiazai/skill9965" title="macOS UI 自动化技能包 —— 用 Python 控制你的 Mac" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
关键限制：
- 只能用字符串传代码，不支持传函数、类或闭包
- 数据交换靠
queue或共享内存（需手动序列化/反序列化） -
_interpreters是私有 C API，不稳定；官方interpreters模块尚未进入标准库（预计 Python 3.13+）
为什么它还是重要？因为它绕开了 GIL 的根本约束
传统 multiprocessing 启动慢、通信重、内存复制开销大；而子解释器启动快（C-level fork）、内存隔离轻量、无需 pickle 序列化（只要不跨解释器共享对象）。但它不是“升级版 threading”，而是另一条路：
- 适合“多个独立计算单元 + 极少交互”的场景，比如并行处理不同用户会话、分片数据清洗、模型推理服务中隔离不同请求
- 不适合需要频繁读写同一字典或共享锁的逻辑
- 当前版本（3.12）必须用 C 扩展或
_interpreters，生产环境慎用；等interpreters进入稳定 API 再考虑迁移
最容易被忽略的一点：子解释器不是线程安全的替代品，而是进程级隔离的轻量替代品——它解决的是“如何在单个进程中启动多个真正并行的 Python 执行环境”，而不是“如何让 threading.Thread 忽略 GIL”。写错抽象层，再新的 GIL 也救不了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
