因为CPython的GIL强制同一时刻仅一个线程执行Python字节码，CPU密集任务无法并行，反而因线程切换和GIL抢占更慢；需用multiprocessing绕过GIL，eBPF可精准追踪PyEval_AcquireLock/ReleaseLock定位持有问题。
为什么 threading 在 CPU 密集场景下几乎不加速？
因为 CPython 的 GIL（全局解释器锁）强制同一时刻只有一个线程执行 Python 字节码。哪怕你开了 8 个 Thread，CPU 密集型任务（比如纯计算、循环累加）依然串行跑，甚至因线程切换和 GIL 抢占反而更慢。
常见错误现象：time.time() 测出来多线程比单线程还慢；top 看到 CPU 占用率卡在 100% 但只用一个核；ps -T -p $PID 显示多个 LWP（轻量级进程），但 /proc/$PID/status 里 thr 数没反映实际并发度。
- 判断是否受 GIL 影响：把核心逻辑换成
time.sleep(1)或requests.get()，这时多线程才明显快——说明原任务是 CPU-bound，不是 I/O-bound - 真正需要并行计算，优先用
multiprocessing，它绕过 GIL，但注意进程间通信开销（Queue、Pipe、SharedMemory） -
concurrent.futures.ThreadPoolExecutor和ProcessPoolExecutor接口一致，换 executor 类型就能快速对比效果
怎么用 eBPF 实时抓到 GIL 抢占和线程阻塞？
eBPF 能在内核态无侵入地观测 Python 解释器的 GIL 操作，关键在于跟踪 CPython 的两个函数：PyEval_AcquireLock 和 PyEval_ReleaseLock。它们在 ceval.c 里定义，是 GIL 加锁/解锁的唯二入口。
使用场景：线上服务响应变慢，怀疑是某段 Python 代码长期持有 GIL；或想确认第三方库（如 NumPy 的某些操作）是否真的释放了 GIL。
立即学习“Python免费学习笔记（深入）”；
- 用
bpftrace快速验证：bpftrace -e 'uprobe:/usr/lib/x86_64-linux-gnu/libpython3.10.so:PyEval_AcquireLock { printf("GIL acquired by %d\n", pid); }' - 注意路径要对：不同 Python 版本、安装方式（apt vs pyenv vs conda）下，
libpython*.so路径不同，可用readelf -d $(which python3) | grep libpython查 - 别直接 hook
PyEval_RestoreThread：它只是封装，底层仍走PyEval_AcquireLock，重复统计会干扰判断
为什么 eBPF trace 显示 GIL 持有时间长，但 Python 代码看起来很短？
常见错觉：一段只有几行的 for 循环被观测到持有 GIL 几百毫秒，怀疑 eBPF 工具不准。其实问题往往出在 C 扩展里——比如调用 numpy.dot()、cv2.cvtColor() 或自研 C 模块时，若没显式调用 Py_BEGIN_ALLOW_THREADS，GIL 就不会释放，整个 C 函数执行期间都算作“Python 线程持有 GIL”。
性能影响：一个耗时 200ms 的 C 函数若没释放 GIL，会阻塞其他 Python 线程整整 200ms，即使它内部全是纯计算。
- 查第三方库是否释放 GIL：看其源码里有没有
Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS，或查文档是否标注 “releases GIL” - 自己写 C 扩展时，务必在计算密集段包裹线程允许宏；否则用
cffi或pybind11时也要手动控制 - eBPF 输出里如果看到某个
pid长时间不触发PyEval_ReleaseLock，就顺着它的调用栈（用bpftrace的ustack）定位到具体 Python 行号和 C 函数
可视化 GIL 热点时，perf script 和 ebpf-exporter 怎么选？
目标不同，工具就该分清：临时排查用 perf 快速出火焰图；长期监控用 ebpf-exporter 接 Prometheus + Grafana。
兼容性影响：CPython 3.12 开始默认启用 “free-threaded” 构建（即无 GIL），但目前绝大多数发行版和 pip 包仍基于传统构建，所以观测脚本需明确指定 Python 版本和构建类型。
-
perf record -e 'syscalls:sys_enter_futex' -p $PID可间接反映 GIL 争用（因为 CPython 用 futex 实现锁），但不如直接 hookPyEval_*精准 -
ebpf-exporter的python_gil_held_seconds_total指标单位是秒，聚合时注意用rate()而非sum()，否则数值会随采样窗口线性增长 - 别把 eBPF 观测和应用日志混在一起做关联分析：eBPF 时间戳是纳秒级，Python 日志是毫秒级，直接 join 容易错位；建议统一用 trace_id 或通过
os.getpid()+ 时间窗对齐
