Python单线程跑不满CPU核因CPython的GIL限制，纯计算任务被锁在单核；但numpy等C扩展可释放GIL实现多核并行，I/O任务则因GIL释放而受益。
Python 单线程为什么跑不满一个 CPU 核？
CPython 解释器有全局解释器锁（GIL），它让同一时刻只有一个线程执行 Python 字节码。哪怕你用 threading.Thread 启了 10 个线程，纯计算任务（比如循环、数值运算）仍然被 GIL 锁死在单核上——不是系统不让，是解释器自己拦着。
常见错误现象：top 或任务管理器里看到 CPU 使用率卡在 100%（单核满载），但程序响应变慢、吞吐没提升，甚至更差。
- 纯 CPU 密集型任务（如加密、矩阵乘、解析大 JSON）几乎无法靠多线程提速
- I/O 密集型任务（如发 HTTP 请求、读文件）能受益，因为阻塞时
GIL会被释放 - 如果你用的是
asyncio，它不绕过GIL，但通过协程调度减少上下文切换开销，在 I/O 场景下比线程更轻量
怎么测出你代码的真实单线程瓶颈？
别猜，直接看：用 perf record -g -e cycles:u python your_script.py（Linux）或 py-spy record -o profile.svg --pid $PID，能定位到真正耗时的函数和 C 扩展调用点。
使用场景：
立即学习“Python免费学习笔记（深入）”；
你想确认是 Python 层逻辑慢，还是底层 C 库（如
numpy、regex）在扛压你改了算法，但速度没变，需要排除
GIL外的干扰（比如内存带宽、缓存命中率）time.perf_counter()测端到端，但掩盖内部热点cProfile能看到函数调用次数和累计时间，但对 C 扩展（如numpy.dot）只记一次调用，实际耗时可能占 90%如果
cProfile显示<built-in method></built-in>占比极高，说明瓶颈在 C 层，这时单线程性能已接近该库在当前硬件上的理论上限
哪些操作能突破单线程“软极限”？
不是所有“单线程”都等于“被 GIL 死死按住”。有些路径天然绕开或弱化 GIL 影响：
-
numpy、scipy、pandas的多数数组运算：底层用 C/Fortran 实现，且显式释放GIL，所以多核 CPU 能并行跑满 -
ctypes或cffi调用的 C 函数：只要你在 C 侧不主动操作 Python 对象，就能全程不碰GIL -
subprocess.run()启外部进程：完全脱离 Python 运行时，CPU 利用率取决于子进程本身 -
asyncio+aiohttp等异步库：虽仍受GIL约束，但避免线程创建/切换开销，在高并发 I/O 下吞吐明显高于同步线程池
注意：concurrent.futures.ProcessPoolExecutor 是真多进程，能绕开 GIL，但它有进程启动、序列化（pickle）开销，小任务反而更慢。
单线程性能的物理天花板在哪？
取决于三件事：CPU 主频 × 指令级并行能力 × 内存带宽。比如一段纯循环累加：
total = 0
for i in range(10**8):
total += i * 2 + 1
在现代 CPU 上，实际每秒执行约 1–3 亿次 Python 字节码（非机器指令），而同样逻辑用 numpy.arange(10*<em>8).sum() </em> 2 + 10**8 可快 50–100 倍——因为后者把循环压进 SIMD 指令，且无字节码解释开销。
容易被忽略的地方：
- Python 对象模型带来巨大间接成本：每次
+=都要查类型、分配新整数对象、触发引用计数 - 缓存局部性差：列表遍历比 NumPy 数组慢不止十倍，主因是内存布局（指针跳转 vs 连续块）
- 你写的“单线程优化”，很可能只是把瓶颈从 CPU 挪到了内存或磁盘，比如用
str.replace()处理 GB 级文本，最终卡在内存拷贝上
事情说清了就结束
