示例工程教程【免费下载链接】materialsBonus materials, exercises, and example projects for our Python tutorials项目地址https://gitcode.com/gh_mirrors/ma/materials点击查看免费下载本篇指南以 python-parallel-processing/README.md 的主题——Bypassing the GIL for Parallel Processing in Python——为核心骨架结合仓库内从入门对比到综合实战的全套示例代码系统讲解 Python 的 GIL 是什么、为什么它会限制多线程并行以及四种主流的绕过方案多进程、GIL 免疫库、C 扩展、Cython、ctypes。读完本文你将掌握每条技术路线的原理、可复制的实现代码与编译/运行命令并能依据任务类型CPU 密集、数据传递、纯 C 重写做出正确的选型决策。一、GIL 问题速览为什么纯 Python 多线程并行不起来CPython 解释器通过全局解释器锁Global Interpreter LockGIL保证同一时刻只有一个线程在执行 Python 字节码。这意味着纯 Python 写的 CPU 密集型代码用多少线程都只能串行执行线程切换带来的反而是额外的上下文切换开销。仓库用两组对照代码把这个问题直观地展示出来Fibonacci.javaJava 直接按 CPU 核数启动线程每个线程递归计算fib(45)线程可以在多核上真正并行fibonacci.pyPython 同样按os.cpu_count()启动线程却只敢计算fib(35)。从这两份代码的对比可以推断出关键信息同样是按核数开满线程跑斐波那契Java 用的递归深度是 45而 Python 只用 35。因为受 GIL 约束Python 线程无法并行作者只能调低计算规模让两边在相近的时间内跑完——这正是GIL 串行化最直观的注脚# fibonacci.py —— 纯 Python 多线程被 GIL 拖成串行 import os import threading def fib(n): return n if n 2 else fib(n - 2) fib(n - 1) for _ in range(os.cpu_count()): threading.Thread(targetfib, args(35,)).start()// Fibonacci.java —— Java 多线程可以真正并行 public class Fibonacci { public static void main(String[] args) { int cpus Runtime.getRuntime().availableProcessors(); for (int i 0; i cpus; i) { new Thread(() - fib(45)).start(); } } private static int fib(int n) { return n 2 ? n : fib(n - 2) fib(n - 1); } }二、路线一进程级并行multiprocessing / ProcessPoolExecutor既然进程不共享解释器和 GIL最直接的绕过方案就是把任务切到多个进程上。仓库 02_process-based_parallelism/ 给出了三种从底层到高层的写法。2.1 手动管理进程multiprocessing.Process01_fibonacci_multiprocessing.py 与纯线程版结构几乎一致只是把threading.Thread换成multiprocessing.Processimport multiprocessing def fib(n): return n if n 2 else fib(n - 2) fib(n - 1) if __name__ __main__: for _ in range(multiprocessing.cpu_count()): multiprocessing.Process(targetfib, args(35,)).start()注意它把启动逻辑放进了if __name__ __main__:保护块——这是多进程编程的必备约定每个子进程在 Windows 等平台会重新导入主模块若无此保护会递归地启动进程。2.2 进程池multiprocessing.Pool手动创建、join 每个进程太繁琐。02_fibonacci_multiprocessing_pool.py 展示了用进程池批量计算fib(0) ~ fib(39)的写法import multiprocessing def fib(n): return n if n 2 else fib(n - 2) fib(n - 1) if __name__ __main__: with multiprocessing.Pool(processes4) as pool: results pool.map(fib, range(40)) for i, result in enumerate(results): print(ffib({i}) {result})Pool.map(fib, range(40))会把 40 个任务分发给 4 个 worker 进程并按输入顺序收集结果with块退出时自动清理进程池。2.3 现代写法concurrent.futures.ProcessPoolExecutor03_fibonacci_concurrent_futures_process_pool.py 使用concurrent.futures高层 API接口与线程池完全对称日后在进程池/线程池之间切换成本最低from concurrent.futures import ProcessPoolExecutor def fib(n): return n if n 2 else fib(n - 2) fib(n - 1) if __name__ __main__: with ProcessPoolExecutor(max_workers4) as executor: results executor.map(fib, range(40)) for i, result in enumerate(results): print(ffib({i}) {result})2.4 代价演示进程间传递数据的开销echo benchmark多进程不是免费的任务参数和返回值必须在进程间序列化pickle传输。04_echo_benchmark.py 用一个回声任务量化了这一成本——echo()原样返回输入没有任何计算量却要在线程/进程池间搬运一个包含 1500 万个复数complex(i, i)的列表import time from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor def echo(data): return data if __name__ __main__: data [complex(i, i) for i in range(15_000_000)] for executor in ThreadPoolExecutor(), ProcessPoolExecutor(): t1 time.perf_counter() with executor: future executor.submit(echo, data) future.result() t2 time.perf_counter() print(f{type(executor).__name__:20s}: {t2 - t1:.2f}s)线程池共享同一份内存几乎零拷贝进程池则必须把 1500 万个复数对象 pickle 到子进程再传回耗时显著。这个实验揭示了进程级并行的重要适用边界只有当单任务的计算量远大于数据搬运开销时才划算如果任务轻、数据重进程间通信反而会成为瓶颈。三、路线二把重活交给GIL 免疫的库以 NumPy 为例很多 C 实现的科学计算库在执行耗时计算时会主动释放 GIL让 Python 线程在此期间真正并行。仓库 03_gil-immune_library/numpy_threads.py 展示的是极简的三行代码import numpy as np rng np.random.default_rng() matrix rng.random(size(5000, 5000)) matrix matrix一个 5000×5000 的随机矩阵自乘。从目录命名gil-immune_library即对 GIL 免疫的库和示例设计可以推断矩阵乘法由 NumPy 底层的 BLAS/LAPACK C 实现完成这些代码在运算期间会释放 GIL因此多线程调用 NumPy 时能获得真正的并行加速。运行本示例需要先安装依赖 requirements.txt 中的numpypip install -r python-parallel-processing/03_gil-immune_library/requirements.txt这条路线对业务代码侵入为零但只对底层已经用 C 实现并主动释放 GIL的库有效——这正是它在实战中的主要限制。四、路线三编写释放 GIL 的 C 扩展如果热点逻辑无法交给现成库就用 C 重写它并在耗时计算前后显式释放/重新获取 GIL。仓库 04_extension_module/ 展示了从零编写 CPython C 扩展的全过程。4.1 C 源码与 GIL 释放宏fibmodule.c 的核心结构如下#include Python.h int fib(int n) { return n 2 ? n : fib(n - 2) fib(n - 1); } static PyObject* fibmodule_fib(PyObject* self, PyObject* args) { int n, result; if (!PyArg_ParseTuple(args, i, n)) { return NULL; } Py_BEGIN_ALLOW_THREADS result fib(n); Py_END_ALLOW_THREADS return Py_BuildValue(i, result); }关键点有两处PyArg_ParseTuple(args, i, n)把 Python 传入的参数解析为 C 的intPy_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS这是一对宏展开后分别执行释放 GIL和重新获取 GIL。中间的fib(n)是纯 C 递归不触碰任何 Python 对象因此可以安全地在无锁状态下运行。文件的其余部分PyMethodDef、PyModuleDef、PyInit_fibmodule是标准扩展模块样板定义模块内的方法表、模块元信息以及模块初始化入口。4.2 编译命令compile.sh 用 gcc 直接编译出共享库gcc $(python3-config --cflags) -shared -fPIC -O3 -o fibmodule.so fibmodule.cpython3-config --cflags注入当前 Python 的头文件搜索路径-shared -fPIC生成位置无关的动态共享库.so-O3开启最高级别优化对递归计算尤其重要。4.3 在 Python 中多线程调用fibonacci_ext.py 与最初的纯 Python 版本代码几乎相同唯一区别是把fib换成了 C 扩展提供的高性能版本并把递归参数恢复到了与 Java 实验一致的45import os import threading import fibmodule for _ in range(os.cpu_count()): threading.Thread(targetfibmodule.fib, args(45,)).start()因为扩展在执行期间释放了 GILos.cpu_count()个线程可以真正并行地计算fib(45)——同样的线程模型在纯 Python 下被 GIL 串行化在 C 扩展下则获得完整的多核加速。从fib(35)回到fib(45)这个细节可以推断作者刻意用与 Java 相同的计算规模来证明C 扩展 释放 GIL已经抹平了语言层面的差距。五、路线三进阶用 Cython 省去手写样板代码手写 CPython C API 样板代码容易出错。仓库 05_extension_module_cython/ 给出了 Cython 的两套等价写法。5.1 经典 .pyx 写法fibmodule.pyx 用nogil关键字声明不持有 GIL的代码段cpdef int fib(int n): with nogil: return _fib(n) cdef int _fib(int n) noexcept nogil: return n if n 2 else _fib(n - 2) _fib(n - 1)cpdef int fib(int n)生成一个可同时被 C 和 Python 调用的函数函数体用with nogil:包裹进入时释放 GILcdef int _fib(int n) noexcept nogil纯 C 级别的递归辅助函数声明为nogil且noexcept不抛异常彻底运行在无 GIL 环境下。5.2 纯 Python 装饰器写法可回退执行有趣的是仓库还提供了一个不用.pyx的替代实现 fibmodule.py它用 Cython 的装饰器把纯 Python 代码标注为可编译import cython cython.ccall def fib(n: cython.int) - cython.int: with cython.nogil: return _fib(n) cython.cfunc cython.nogil cython.exceptval(checkFalse) def _fib(n: cython.int) - cython.int: return n if n 2 else _fib(n - 2) _fib(n - 1) if cython.compiled: print(Cython compiled this module) else: print(Cython didnt compile this module)这段代码的巧妙之处在于它具备双重身份未编译时它是合法的纯 Python 模块cython.nogil等对象可以 import直接用 Python 解释器也能运行用 Cython 编译后cython.compiled为真cython.ccall/cython.cfunc定义的函数被编译成 C 代码并释放 GIL。文件末尾的if cython.compiled:分支会在运行时明确告诉你当前这份代码到底有没有被编译。5.3 编译命令compile.sh 使用 Cython 自带的命令行工具cythonize --inplace --annotate -3 fibmodule.py--inplace把生成的扩展就地编译为.so不移动源文件--annotate生成 HTML 标注文件用颜色标出每一行被编译为 C 的比率黄色越少说明 Python 交互越少、性能越好-3面向 Python 3 语法。编译完成后fibonacci_ext.py 的调用方式与上一节完全一致——多线程、每线程fib(45)、不碰 GIL。依赖见 requirements.txt。六、路线四ctypes 直接调用共享库零样板如果 C 函数本身不依赖任何 CPython API可以用 ctypes 直接加载编译好的共享库完全避开扩展模块样板。6.1 纯 C 库fibonacci.c 是没有任何 Python 依赖的普通 C 文件int fib(int n) { return n 2 ? n : fib(n - 2) fib(n - 1); }compile.sh 的编译命令比扩展模块更简单——不需要python3-configgcc -shared -fPIC -O3 -o fibonacci.so fibonacci.c6.2 用 ctypes 声明并多线程调用fibonacci_ctypes.py 展示了完整流程import ctypes import os import threading fibonacci ctypes.CDLL(./fibonacci.so) fib fibonacci.fib fib.argtypes (ctypes.c_int,) fib.restype ctypes.c_int for _ in range(os.cpu_count()): threading.Thread(targetfib, args(45,)).start()要点ctypes.CDLL(./fibonacci.so)加载动态库通过fib.argtypes (ctypes.c_int,)和fib.restype ctypes.c_int显式声明 C 函数的签名这既是类型安全的需要也能避免默认整型转换带来的隐患调用fib时 ctypes 会在 C 函数执行期间自动释放 GIL在 ctypes 内部实现中外部 C 调用默认不持有 GIL因此多个线程可以并行执行fib(45)无需编写任何 Python 绑定代码。这条路线最适合已有现成 C/C 库、不想为 Python 写绑定的场景代价是函数签名、内存所有权等细节需要开发者自行管理。七、综合实战C 扩展 多线程的图像曝光/Gamma 校正应用仓库把前面所有技术串成了一个可运行的实战项目07_image_processing/。这是一个基于 Tkinter 的桌面应用实时调节照片的曝光Exposure与 Gamma 值其中像素处理由 C 扩展完成、由多线程并行执行。7.1 并行 C 内核按颜色通道分片parallel/parallel.c 定义了process()函数它先构建 256 级查找表lookup table再对像素数组的三分之一做映射#include math.h void process( unsigned char* pixels, int length, int offset, float ev, float gamma) { unsigned char lookup_table[256]; for (int i 0; i 256; i) { float value powf((i / 255.0f * ev), gamma) * 255.0f; lookup_table[i] (unsigned char) fmin(fmax(0.0f, value), 255.0f); } for (int i offset; i length; i 3) { pixels[i] lookup_table[pixels[i]]; } }核心设计是循环里的i 3与入口参数offsetRGB 像素在内存中是连续的三字节R、G、Boffset0处理 R 通道offset1处理 G 通道offset2处理 B 通道。三个线程分别处理三个互不相交的通道不存在写冲突因此无需任何锁就可以安全并行。7.2 ctypes 包装三个线程各处理一个通道parallel/init.py 扮演胶水层加载编译产物、声明 C 签名并把三个线程的编排封装成一个process(pixels, ev, gamma)函数import ctypes import pathlib import threading import numpy as np library_path str(pathlib.Path(__file__).parent / f{__package__}.so) library ctypes.CDLL(library_path) UnsignedByteArrayPointer ctypes.POINTER(ctypes.c_ubyte) library.process.argtypes [ UnsignedByteArrayPointer, # unsigned char* pixels ctypes.c_int, # int length ctypes.c_int, # int offset ctypes.c_float, # float ev ctypes.c_float, # float gamma ] def process(pixels: np.ndarray, ev: float, gamma: float) - None: pointer pixels.ctypes.data_as(UnsignedByteArrayPointer) threads [ threading.Thread( targetlibrary.process, args(pointer, pixels.size, offset, ev, gamma), ) for offset in range(3) ] for thread in threads: thread.start() for thread in threads: thread.join()值得注意的实现细节pixels.ctypes.data_as(...)把 NumPy 数组的内存缓冲直接暴露为unsigned char*零拷贝传给 C传入的length是pixels.size像素总数配合 stride 3 恰好覆盖全部 RGB 字节offset取0/1/2三个值各起一个线程start 后 join即三路并行、等待全部完成。7.3 Tkinter 前端拖动滑块即触发并行处理image_processing.py 是主程序窗口标题为 Exposure and Gamma Correction包含一个 EV 滑块范围-1 ~ 1初值 0和一个 Gamma 滑块范围0.1 ~ 2初值 1。滑块拖动事件绑定到on_slide()def on_slide(self, *args, **kwargs) - None: ev 2.0 ** self.var_ev.get() gamma 1.0 / self.var_gamma.get() t1 time.perf_counter() pixels self.pixels.copy() parallel.process(pixels, ev, gamma) t2 time.perf_counter() image PIL.Image.fromarray(pixels) self.show_preview(image) t3 time.perf_counter() self.var_status.set( fProcessed in {(t2 - t1) * 1000:.0f} ms f(Rendered in {(t3 - t1) * 1000:.0f} ms) )参数换算逻辑体现了摄影常识滑块值ev先经2.0 ** ev换算成曝光倍率Gamma 取倒数1.0 / gamma后才送入 C 函数。状态栏会实时显示像素处理耗时与预览渲染耗时两个指标方便直接观察并行 C 内核的毫秒级性能。7.4 三模式对比版Python / NumPy / Parallelimage_processing_bonus.py 是扩展版本界面增加了一个 Mode 下拉框内置三种处理模式enum.StrEnumclass ProcessingMode(enum.StrEnum): PYTHON Python NUMPY NumPy PARALLEL Parallel (GIL-Free)process()用match语句分发到三种实现process_python()用纯 Python 列表推导逐像素查表——最慢的基线process_numpy()用np.arange(256)向量化构建查找表再lookup_table[pixels]一次性索引——NumPy 的 GIL 免疫路径Parallel走parallel.process()的 C 多线程路径。def process_python(pixels: np.ndarray, ev: float, gamma: float) - np.ndarray: lookup_table [ int(min(max(0, (((i / 255.0) * ev) ** gamma) * 255), 255)) for i in range(256) ] values [lookup_table[x] for x in pixels.flat] return np.array(values).astype(np.uint8).reshape(pixels.shape) def process_numpy(pixels: np.ndarray, ev: float, gamma: float) - np.ndarray: lookup_table ( ((((np.arange(256) / 255.0) * ev) ** gamma) * 255) .clip(0, 255) .astype(np.uint8) ) return lookup_table[pixels]在同一张图上切换三种模式状态栏会显示各自的处理耗时——这是一个非常直观的三种 GIL 策略实时对比实验台。7.5 编译与运行运行前先编译 C 扩展依赖见 requirements.txt含numpy与pillowcd python-parallel-processing/07_image_processing/parallel bash compile.sh然后回到07_image_processing目录用仓库自带的示例图启动应用python image_processing.py sample_image_small.jpg仓库提供了两张不同规格的测试素材sample_image_small.jpg1920×1080与 sample_image_big.jpg11296×3808约 13 MB。想体验大数据量下的并行效果可以换用大图python image_processing_bonus.py sample_image_big.jpg注意示例依赖 Tkintertkinter/PIL.ImageTk需要在带图形界面的桌面环境中运行parallel.so需与本机 Python/glibc 兼容重新编译可保证一致性。八、路线总结与选型建议结合仓库 python-parallel-processing/ 的完整示例四条绕过 GIL 的技术路线可以汇总如下路线仓库示例目录适用场景核心代价/限制多进程multiprocessing / ProcessPoolExecutor02_process-based_parallelism/CPU 密集型纯 Python 代码进程间数据需 pickle 序列化通信开销大echo基准测试可量化GIL 免疫库NumPy 等03_gil-immune_library/计算已被 C 实现且底层主动释放 GIL 的库无法覆盖任意自定义逻辑手写 C 扩展Py_BEGIN_ALLOW_THREADS04_extension_module/热点逻辑用 C 重写需要完整控制需要维护 CPython C API 样板代码Cythonnogil / cythonize05_extension_module_cython/想用近似 Python 的语法获得 C 扩展能力需要 Cython 工具链.pyx/装饰器写法二选一ctypes 调用现成共享库06_ctypes/已有 C/C 库不想写绑定函数签名、内存管理需手动声明综合实战 07_image_processing/ 则演示了ctypes 多线程 无锁分片的组合拳parallel.c用 stride 3 把 RGB 像素按通道切成三段三个线程各处理一段互不重叠的数据在完全不需要加锁的前提下实现了真正的多核并行同时把纯 Python、NumPy、并行 C 三种模式的耗时放进同一个 GUI 里供实时对比。最终选型建议业务逻辑依赖现成数值库时优先选 NumPy 等 GIL 免疫库纯 Python 计算密集且不在乎进程启动与序列化成本时选 multiprocessing追求极致性能且愿意维护 C 代码时手写扩展或 Cython 是更优解而手头已有现成 C 库时ctypes 能以最小的侵入成本立刻获得多线程并行能力。所有示例代码均可在仓库python-parallel-processing/目录下直接查看、编译与运行。赞分享示例工程教程【免费下载链接】materialsBonus materials, exercises, and example projects for our Python tutorials项目地址https://gitcode.com/gh_mirrors/ma/materials点击查看免费下载相关推荐spaCy 自然语言处理实战materials 仓库示例代码深度解析spaCy 自然语言处理实战materials 仓库示例代码深度解析 本文围绕开源仓库 materials 中 spacy 目录下的配套文档与示例代码系统讲示例工程教程Python 3.13 新特性实战指南基于 materials 仓库示例代码的完整演练Python 3.13 新特性实战指南基于 materials 仓库示例代码的完整演练 导读 本指南以仓库 python 313/README.md http示例工程教程Python while 循环完整实战指南用条件控制重复任务附 materials 仓库代码示例Python while 循环完整实战指南用条件控制重复任务附 materials 仓库代码示例 导读 本文围绕 materials 开源仓库中 pyth示例工程教程上一篇Ghostty 嵌入式终端着色实践:用 libghostty-vt C 库设置默认颜色、读取生效值并观察 OSC 覆盖下一篇ccg-workflow 的 /ccg:codex-exec 全权执行模式Codex 承担 MCP 搜索与实现Claude 只做轻量审核创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考