配置gunicorn请求前后开关Garbage Collection有什么副作用？

• 异常场景下永久内存泄漏风险：如果请求处理过程中抛出未捕获异常、触发gunicorn超时中断，会直接跳过post_request的GC开启逻辑，对应worker进程的GC会永久处于关闭状态，后续该worker处理的所有请求都不会执行内存回收，内存会持续上涨直到进程被OOM杀死，风险远高于原有的内存预留问题。
• 单请求处理阶段OOM风险：请求处理全程关闭GC，所有临时对象、循环引用垃圾都不会被回收，若单请求需要处理大量数据、逻辑链路长，还没等到请求结束开启GC，进程就会因内存占用超限被OOM杀掉，反而会加剧K8s pod重启的问题。
• 接口响应延迟抖动加剧：整个请求周期产生的垃圾会攒到请求结束后一次性回收，单次GC的Stop The World（STW）停顿时间远高于常规增量GC，高并发场景下大量请求同时结束触发GC时，会出现大面积接口响应超时、服务可用性下降。
• 与应用/依赖的GC逻辑冲突：如果应用代码、依赖的第三方库本身手动调整过GC阈值、主动调用gc.collect()执行回收，强制在请求层面开关GC会打乱原有内存管理逻辑，轻则出现预期外的内存占用上涨，重则触发不可复现的内存错误、段错误。
• 第三方库兼容性问题：大量Python第三方库（尤其是数据处理、序列化、IO相关库）的资源回收逻辑依赖默认GC机制，GC关闭时，库产生的临时对象、绑定的文件句柄/网络连接等资源无法及时释放，会出现资源泄漏、返回结果异常等问题。
• 同进程异步任务受影响：如果worker进程内同时运行异步后台任务，请求处理阶段关闭GC时，异步任务产生的垃圾也无法回收，同样会出现内存占用异常上涨的问题。

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