Python进程池“阻塞”实为调度、序列化、资源竞争或系统限制所致：未及时get结果、传入不可序列化对象、未正确close/join、或ulimit超限。
Python进程池（multiprocessing.Pool）出现“阻塞”，通常不是池本身卡死，而是任务调度、资源竞争或调用方式不当导致的表象。核心问题往往出在：任务提交后未及时获取结果、子进程内部阻塞、或主进程等待方式不合理。
任务提交后未显式获取结果，造成隐式阻塞
使用 pool.apply_async() 提交任务时，若不主动调用 .get() 或未设置超时，后续调用 .get() 时会一直阻塞直到结果就绪——哪怕其他任务早已完成。
- 错误写法：
result = pool.apply_async(func, args); print(result.get())—— 若 func 执行慢，此处立即阻塞 - 推荐做法：批量提交后统一非阻塞轮询，或用
pool.map()/pool.starmap()（它们内部自动同步，适合同构任务） - 进阶方案：用
async_result.ready()判断状态，配合time.sleep()轮询，避免单点阻塞
子进程内存在不可序列化或全局锁竞争
进程池通过 pickle 序列化参数和函数发送给子进程。若传入含文件句柄、线程锁、数据库连接等不可序列化对象，apply_async 会卡在序列化阶段，看似“阻塞”；此外，多个子进程争抢同一全局资源（如未加锁的共享文件写入），也可能因等待锁而停滞。
- 检查函数和参数是否可被 pickle：尝试
pickle.dumps(obj)验证 - 避免在子进程中直接操作主进程创建的资源（如 open 的文件、threading.Lock 实例）
- 如需共享状态，改用
multiprocessing.Manager()或multiprocessing.Value/Array
进程池未正确关闭与等待，导致主进程挂起
调用 pool.close() 后未接 pool.join()，或在 join() 前仍有任务提交，都会引发异常或行为不确定；更常见的是，在 join() 时子进程因异常崩溃未退出，主进程无限等待。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 标准流程应为：
pool.map(...)→pool.close()→pool.join() - 若需提前终止，用
pool.terminate()强制杀掉所有子进程（但会丢失未完成结果） - 调试时可在子进程函数开头加
print(os.getpid(), 'started')，确认是否真正启动
系统级限制引发的假性阻塞
Linux 下默认每个用户进程数有限（ulimit -u），大量进程池 + 高 processes 参数可能触发限制；Windows 对命名管道、句柄数量也更敏感。此时新进程无法创建，apply_async 表现为长时间无响应。
- 运行
ulimit -u查看最大用户进程数，必要时调高（需权限） - 避免设置
processes > os.cpu_count()过多，尤其 I/O 密集型任务无需过多进程 - 用
ps aux | grep python | wc -l（Linux）或任务管理器（Windows）观察实际进程数是否异常增长
不复杂但容易忽略。关键在分清是调度逻辑阻塞、序列化失败、资源竞争，还是系统瓶颈——定位清楚，基本就能解。
