Gunicorn预fork同步worker是否共享数据库连接池？

你的判断完全正确，Gunicorn的sync同步worker之间不会共享数据库连接池这类应用层资源，你同事的观点不符合pre-fork模型的实际运行逻辑。

Gunicorn sync模式的底层运行逻辑 #

• Gunicorn基于经典的pre-fork模型实现，启动后首先运行主进程（master），主进程不处理任何业务请求，只负责监听服务端口、按配置fork指定数量的worker进程、监控worker状态、做平滑重启/重载这类管控操作。
• 当你配置workers=5时，主进程会fork出5个完全独立的操作系统进程，每个子进程会独立加载完整的WSGI应用代码。操作系统层面进程间内存地址空间是完全隔离的，除非你主动引入跨进程共享组件（比如外部缓存、共享内存段），否则各进程的全局变量、初始化的资源全都是独立持有的，不存在自动共享的可能。

数据库连接池的实际表现 #

• sync worker采用单进程串行执行模型：一个worker同一时间最多处理1个请求，当前请求处理完成后才会接收下一个请求，进程内部不存在多线程/协程并发争抢资源的场景。
• 这种模式下如果配置应用层数据库连接池，比如设置单池大小为10，那么5个worker会各自初始化一个独立的连接池，最坏情况下会占用5*10=50个数据库连接，非常容易打满数据库的最大连接数上限，属于完全没必要的资源浪费。
• 针对sync worker部署场景，数据库访问不需要配置连接池，每个worker进程维持1个长连接复用即可，既足够支撑业务，也不会产生多余的连接开销。

常见认知误区澄清 #

很多人会把多进程和多线程的资源逻辑搞混，这里特意说明：

• 如果使用的是gthread（线程型worker）、gevent/eventlet（协程型worker），同一个worker进程内的执行单元是共享进程内存的，这种场景下才需要配置连接池，池大小和同进程内的并发线程/协程数匹配即可。
• 额外提一个高频踩坑点：不要在Gunicorn主进程加载阶段（比如模块顶层、post_fork钩子执行前）初始化数据库连接。因为fork操作会把主进程的文件描述符拷贝给所有子进程，会出现多个进程争抢同一个数据库连接socket的问题，随机触发查询结果错乱、连接断开、协议报错等很难排查的异常。数据库连接这类持有系统fd的资源，一定要放在post_fork钩子之后、也就是子进程启动阶段再初始化。

内容的提问来源于stack exchange，提问作者beginner_