Gunicorn + ThreadPoolExecutor如何处理多用户并发请求，避免后台任务异常中断

• concurrent.futures.ThreadPoolExecutor 默认生成的是守护线程，守护线程会跟随所属进程的主线程退出而被立刻强制终止。如果你使用gunicorn默认的sync同步worker，worker主线程仅在处理请求时存活，请求处理完毕返回响应后如果没有新的请求接入，worker进程的主线程进入空闲状态时可能触发守护线程回收，导致未跑完的后台任务被终止。
• 默认gunicorn的sync同步worker同一时间仅能处理1个请求，多请求排队时会干扰后台线程的调度逻辑，同时如果未指定worker数量，单worker进程的线程资源有限也可能导致任务被强制中断。
• 如果你的长任务逻辑存在未加锁的全局资源竞争，多个任务同时操作同一个资源时会抛出异常退出，看起来像是被系统终止。

方案1：改造现有代码及启动参数（适合轻量场景） #

第一步：修改线程池配置，禁用守护线程 #

自定义线程工厂，将线程池生成的线程设置为非守护线程，避免被主线程意外回收：

import falcon
import threading
from concurrent.futures import ThreadPoolExecutor

def non_daemon_thread_factory():
    def factory(target):
        t = threading.Thread(target=target)
        t.daemon = False
        return t
    return factory

# 初始化线程池时指定自定义线程工厂
executor = ThreadPoolExecutor(
    max_workers=10,
    thread_factory=non_daemon_thread_factory()
)

class Resource:
    def on_post(self, req, resp):
        def some_long_task():
            # 长任务逻辑，注意如果有共享资源要加锁
            pass
            
        executor.submit(some_long_task)
        
        resp.text = 'OK'  # falcon 3.0+版本推荐用resp.text替代旧的resp.body
        resp.status = falcon.HTTP_201
        
app = falcon.App()
resource = Resource()
app.add_route('/', resource)

第二步：调整gunicorn启动参数 #

改用gthread异步worker类型，指定合理的worker数量，适配多线程后台任务场景：

gunicorn main:app --worker-class gthread --workers 2 --threads 12 --timeout 10000

参数说明：

• --worker-class gthread：使用多线程worker，原生支持多线程调度，不会因为请求处理完毕就回收后台线程
• --workers 2：worker进程数，推荐设置为CPU核心数的1~2倍
• --threads 12：每个worker进程的请求处理线程数，略大于你线程池的max_workers即可

第三步：排查长任务逻辑 #

检查长任务中是否存在全局变量、文件句柄、数据库连接等共享资源的操作，涉及写操作要加线程锁，避免多任务竞争导致异常退出。

方案2：生产级高可靠方案（适合正式环境） #

进程内线程池的任务会随着worker进程的重启、崩溃丢失，生产环境建议使用独立的分布式任务队列托管长耗时任务，轻量场景可以用RQ（Redis Queue），复杂调度场景可以用Celery。只需在API接口中把任务参数丢到任务队列就返回响应，由独立的worker进程消费执行任务，完全和API服务的生命周期解耦，不会出现任务被意外终止的问题。

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