多线程不提速是因gil限制cpu密集型任务并行，应改用multiprocessing；每个进程有独立gil和内存，可真并行，但需注意序列化、启动开销、windows入口保护及共享状态陷阱。
多线程不提速，不是代码写错了，是 GIL 在锁死 CPU 密集型任务。 你用 threading 或 concurrent.futures.ThreadPoolExecutor 处理图像缩放、文本解析、数值计算这类任务时，耗时反而比单线程长，根本原因就在这里——Python 的全局解释器锁（GIL）强制所有线程轮流执行 Python 字节码，无法真正并行。解决办法很直接：换 multiprocessing。
为什么 multiprocessing.Process 比 threading.Thread 快？
每个 multiprocessing.Process 运行在独立的 Python 解释器进程中，拥有自己的内存空间和 GIL，因此能绕过 GIL 限制，在多核 CPU 上真正并行执行。
- 适用于 CPU 密集型任务：如图像解码、特征编码、矩阵运算、正则匹配等
- 不适用于频繁跨进程传递大对象的场景（序列化开销高）
- 启动开销比线程大，适合单次任务耗时 ≥ 100ms 的场景
- Windows 下必须将进程创建逻辑放在
if __name__ == '__main__':块内，否则会递归启动新进程
用 Pool.map 替代 ThreadPoolExecutor.map
这是最常用也最稳妥的替换方式，接口几乎一致，但底层走的是进程池而非线程池。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 原多线程写法：
ThreadPoolExecutor(max_workers=4).map(func, data_list) - 改多进程写法：
from multiprocessing import Pool; with Pool(4) as p: p.map(func, data_list) - 注意：
func必须是可序列化的顶层函数（不能是 lambda、嵌套函数或类方法） - 如果
func需要多个参数，用functools.partial或封装成接受元组的函数
共享状态与通信的常见陷阱
进程间默认不共享内存，global 变量、类属性、模块级缓存在子进程中都是副本，修改不会回传。
- 不要依赖全局变量缓存配置或中间结果——每次进程启动都会重新加载模块
- 需共享只读数据（如大字典、模型权重）时，用
multiprocessing.Manager().dict()或multiprocessing.Array，但有性能损耗 - 更高效的做法是：把只读数据作为参数传入函数，或在子进程内按需加载（例如每个进程自己
torch.load模型） - 避免在
map中做文件写入竞争——不同进程同时写同一文件会出错，应让每个进程写独立路径
实际加速效果取决于任务粒度与 I/O 比例
不是开了 8 个进程就一定快 8 倍。真实瓶颈可能藏在别处：
- 如果单个
process_image耗时仅 5ms，进程启动/通信开销可能占主导，此时建议批量处理（如每进程处理 100 张图） - 若任务含大量磁盘读取（如遍历 10 万张小图），I/O 本身成瓶颈，加进程数反而引发磁盘争抢，此时应配合异步读取（
aiofiles）或预加载到内存 - CPU 核心数 ≠ 最优进程数；通常设为
os.cpu_count() - 1更稳，留一个核给系统调度
最容易被忽略的一点：你写的“预处理函数”是否真的在做 CPU 工作？比如用 PIL.Image.open 读图后立刻 .convert('L')，这部分是纯 CPU 计算；但如果只是 open + save，那本质是 I/O，此时多进程收益有限，甚至不如多线程+预读缓冲。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
