thread_map对numpy计算无效，因gil导致线程频繁争抢与上下文切换开销；process_map虽可并行，但默认pickle拷贝大数组引发内存与序列化瓶颈，需用shared_memory等共享机制优化。
thread_map 在 NumPy 计算中通常不提速，甚至更慢——这不是你代码写错了，而是 GIL 和线程调度机制决定了它不适合 CPU 密集型任务。
为什么 thread_map 对 NumPy 计算无效？
NumPy 的底层数学运算（如 np.mean、np.std）虽会释放 GIL，但前提是：调用足够重、持续时间足够长。而现实中很多“计算任务”实际包含大量 Python 层逻辑（索引切片、条件判断、函数调用开销），导致线程频繁争抢 GIL，反而增加上下文切换成本。
- 每个线程启动/销毁本身有固定开销，小任务下开销占比极高
-
thread_map无法绕过 GIL 管理的内存对象引用计数更新，尤其在频繁创建/销毁临时数组时 - 即使底层 C 运算释放了 GIL，Python 解释器仍需在返回前重新获取 GIL，形成“释放-抢锁-执行-再释放”的毛刺循环
什么时候该换用 process_map？又为什么它也常变慢？
process_map 能真正并行，但它默认对每个任务参数做完整 pickle 序列化。当传入的是大型 np.ndarray（比如 shape=(10000, 10000)），每次 fork 子进程都要拷贝整块内存 —— 不是共享，是复制。
- 假设主进程有 2GB 共享数据，5 个 worker 各自拷贝一次 → 额外占用 10GB 内存 + 序列化/反序列化时间
- Linux 下虽有 copy-on-write，但一旦子进程修改数组（哪怕只是读取触发 page fault），就会触发实际拷贝
-
process_map的默认行为不感知 NumPy 数组的内存布局，无法自动启用共享内存优化
怎样让多进程真正快起来？绕过 pickle 拷贝
核心思路：把大数组放到共享内存里，只传索引或视图信息给子进程，避免重复序列化。
- 用
multiprocessing.shared_memory.SharedMemory（Python 3.8+）创建命名共享块，把np.ndarray数据.tobytes()写入，子进程用相同 name 重建数组视图 - 或者用
multiprocessing.Manager().dict()存放数组元信息（shape、dtype、offset），配合numpy.ndarray构造器从共享地址重建 - 更轻量的做法：用
numpy.memmap把数组映射到磁盘文件，各进程直接读同一文件（适合超大数组、IO 带宽够）
示例关键片段：
import numpy as np from multiprocessing import shared_memory, Process from tqdm.contrib.concurrent import process_map <h1>主进程：创建共享内存并填充数据</h1><p>shm = shared_memory.SharedMemory(create=True, size=a.nbytes) shared_arr = np.ndarray(a.shape, dtype=a.dtype, buffer=shm.buf) shared_arr[:] = a[:] # 复制数据进去</p><h1>子进程函数：只接收 shm.name 和 shape/dtype，不传数组本身</h1><p>def calc_on_shared(shm_name): existing_shm = shared_memory.SharedMemory(name=shm_name) arr = np.ndarray(a.shape, dtype=a.dtype, buffer=existing_shm.buf) return np.mean(arr) # 真正计算</p><h1>调用时只传名字，不传数组</h1><p>results = process_map(calc_on_shared, [shm.name] * 4, max_workers=4) shm.close() shm.unlink() # 清理</p>
还有哪些容易被忽略的加速点？
很多人卡在“用了多进程但没变快”，其实问题常出在边界上：
- NumPy 函数本身是否已最优？比如用
np.linalg.norm(x, axis=1)替代手动np.sqrt(np.sum(x**2, axis=1))，前者底层调用高度优化的 BLAS - 是否启用了 OpenBLAS/MKL？没配的话，
np.dot等操作可能只跑单核 - 子进程里是否无意触发了 Python 层循环？例如对共享数组做
for i in range(len(arr)):，这会重新拉起 GIL -
process_map的chunksize默认是 1，小任务建议设为max(1, len(tasks)//os.cpu_count())减少 IPC 频次
真正影响性能的，往往不是“有没有并行”，而是“数据怎么来、结果怎么回、中间有没有隐式 Python 开销”。共享内存那几行代码看着简单，漏掉就白忙活。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
