Python中Celery在3.5之前版本执行zipfile时存在线程安全问题吗？
Python中Celery在3.5之前版本执行zipfile时存在线程安全问题吗？
17 回复
在Celery 3.5之前的版本中，确实存在一个已知的线程安全问题，主要与zipfile模块的使用相关。具体来说，问题出现在Celery的billiard依赖（用于处理进程池）中，当它尝试导入zipfile模块时，可能会在多线程环境下引发竞争条件。
问题根源：
zipfile模块在Python标准库中使用了共享的类级缓存（_ZipDecrypter）。- 在Celery 3.5之前，
billiard在初始化进程池时，会在子进程中导入zipfile模块。 - 如果父进程的多个线程同时创建子进程，可能导致多个线程并发初始化
zipfile，进而引发缓存竞争，最终可能导致RuntimeError或数据损坏。
解决方案：
- 升级到Celery 3.5或更高版本：官方在该版本中修复了此问题，通过避免在子进程中导入
zipfile来消除竞争条件。 - 如果无法升级：可以尝试在程序启动时（在任何线程创建之前）预先导入
zipfile模块，例如在代码开头添加import zipfile。但这只是一种缓解措施，并非完全可靠。
代码示例（缓解措施）：
import zipfile # 在主线程中预先导入
from celery import Celery
app = Celery('myapp')
# 其他配置和任务定义...
总结建议：直接升级Celery到3.5以上版本是最稳妥的解决方案。
python 这种不能用多核的渣渣 压缩不想办法 fork 到其他进程里干 你想卡死当前进程么
再说了 python 性能这么烂 需要经常压缩的话直接 shell 执行是性能最好的, 条件允许能不用 native 代码去压缩就不要用 python 去压文件
celery 有多个模式, prefork (default), eventlet, gevent or solo. 在默认 prefork 模式下开 worker 是多进程，资源都不共享，不存在线程安全问题吧？
参考大家的建议，本地也测试过，情况是这样的：
本地开发环境，单线程直接启动 celery 运行 zipfile 正常；生产环境是多 worker，这个任务里还有个 for 循环，只运行了第一个 loop 就熄火了。（所以整个任务是没有执行完成的，现在先用 thread 扛着在用，线上 celery 的故障还没有找出来）
