Python 3.13 无 GIL 模式需手动编译并验证启用状态，真实加速需用纯 CPU 密集型任务、合理线程数、排除干扰，并与 GIL 版本及 multiprocessing 横向对比。
Python 3.13 的无 GIL 模式（--disable-gil 构建）不是开箱即用的加速开关，它需要你手动编译、验证运行时状态，并用**真实 CPU 密集型负载 + 正确线程数 + 排除干扰因素**才能测出有意义的加速比。盲目跑个 threading.Thread 示例，结果很可能和旧版本一样慢，甚至更差。
确认当前 Python 是否真在无 GIL 模式下运行
很多用户以为装了 Python 3.13 就自动无 GIL，其实完全相反：默认构建仍带 GIL，且官方预编译包（如 python.org 下载的安装包）**全部不包含 --disable-gil 支持**。必须自己编译，且运行时要显式验证：
- 检查是否为自编译的无 GIL 版本：
python3.13 -c "import sys; print(hasattr(sys, '_is_gil_enabled') and not sys._is_gil_enabled())"—— 输出True才算真正启用 - 若报错
AttributeError: module 'sys' has no attribute '_is_gil_enabled'，说明你用的不是--disable-gil构建的解释器 - Linux/macOS 编译命令关键项：
./configure --disable-gil --enable-optimizations && make -j$(nproc)；Windows 需用 MSVC + 显式传参，难度更高
写一个能暴露 GIL 效应的真实基准测试函数
不能用 time.sleep() 或 print()，也不能用 NumPy（它本身会释放 GIL），必须是纯 Python 循环+整数运算，让线程真正卡在字节码执行上：
def cpu_bound_task(n=50_000_000):
total = 0
for i in range(n):
total = total + i * i % 1000 # 避免被简单优化掉
return total
- 单线程调用一次作为 baseline：
cpu_bound_task(50_000_000) - 多线程调用时，每个线程必须处理**等量独立数据**（不要共享变量或锁），例如：
[cpu_bound_task(12_500_000) for _ in range(4)] - 务必用
time.perf_counter()测总耗时，不用time.time()
控制变量：线程数、进程绑定与系统干扰
无 GIL 后线程能并行，但不等于自动满速。常见翻车点包括：
立即学习“Python免费学习笔记（深入）”；
- 线程数设太多（比如 16 线程跑在 8 核 CPU 上），引发上下文切换开销反超收益；建议从
os.cpu_count()开始试 - 未禁用 CPU 频率调节器（如 Linux 的
ondemandgovernor），导致实测时核心降频；推荐切到performance模式 - 测试期间有其他高 CPU 进程（如浏览器、IDE、备份任务）在抢资源；建议关掉 GUI，用
taskset -c 0-7 python test.py绑定核心 - Python 默认使用
pymalloc，而无 GIL 构建需搭配--without-pymalloc才稳定；否则可能触发内存分配竞争，反而拖慢
对比组必须拉齐：GIL vs 无 GIL vs multiprocessing
只测无 GIL 多线程没意义，必须和三个参照系横向比：
- GIL 模式下同代码：同一台机器，换回带 GIL 的 Python 3.13，跑完全相同线程数和任务量
-
multiprocessing.Pool：用
concurrent.futures.ProcessPoolExecutor跑相同任务，作为“绕过 GIL 的传统方案”基线 - 注意冷启动影响：首次运行可能触发 JIT 编译或内存分配延迟，每组至少跑 3 次取中位数
最容易被忽略的是——无 GIL 后，threading.Lock 竞争开销变小，但**Python 对象的引用计数操作不再受全局锁保护，所以共享可变对象（如全局 list、dict）的读写依然需要加锁**。测加速比时，务必确保所有线程操作的是本地变量或不可变数据，否则测出来的是竞态 bug，不是性能。
