Flask应用中能否创建全局ThreadPoolExecutor及相关并发问题

1. 是否可创建全局ThreadPoolExecutor供所有请求共享？这是否能避免重复创建销毁线程池，提升运行效率？ #

• 完全可以创建全局线程池供所有请求共享。每次请求创建销毁线程池会带来线程初始化/销毁的额外开销，全局共享池能复用已创建的线程，彻底避免这类重复开销，确实能显著提升运行效率。
• 注意要点：必须保证全局线程池是单例实例，在Flask应用启动阶段初始化（比如在app = Flask(__name__)之后创建），绝对不能在请求处理函数内部初始化。另外要关注数据库连接的线程安全性——如果每个线程使用独立的数据库连接，或者你的数据库连接池本身是线程安全的（比如SQLAlchemy的内置连接池），就不会出现问题。

2. 若ThreadPoolExecutor的max_workers设置为32，当向共享线程池提交超过32个查询时，该限制会如何作用？ #

• 当提交的任务数超过max_workers设定的32时，超出的任务会被放入线程池内置的任务等待队列中排队。
• 只有当线程池里的某个线程完成当前任务后，才会从队列中取出下一个待执行的任务。整个过程严格遵守max_workers的数量限制，不会额外创建新线程，这样能避免因线程过多导致的上下文切换开销激增和系统资源耗尽问题。

3. 假设：由于线程发送数据库请求时会阻塞，线程池可调度后续查询，因此提交的查询数超过CPU核心数也不会有问题，该假设在Python中是否成立？ #

• 这个假设完全成立。数据库查询属于典型的I/O密集型任务，线程在等待数据库返回结果时会被操作系统挂起（进入阻塞状态），此时Python的GIL（全局解释器锁）会被释放，其他线程可以正常执行。
• 所以即便线程数超过CPU核心数，也能有效利用CPU的空闲时间，处理更多处于阻塞状态的I/O任务，不会出现CPU过载的情况。不过也不是线程越多越好——过多线程会增加上下文切换的开销，建议根据数据库的并发连接限制和服务器实际资源来调整max_workers的数值（32、64都是常见的合理取值）。

当前使用的代码 #

with futures.ThreadPoolExecutor(max_workers=min(32, len(list_of_queries)), thread_name_prefix='query_pool') as tpe:
    future_list = [tpe.submit(execute_query, connection, query) for query in
                   list_of_queries]
    for future in futures.as_completed(future_list):
        try:
            # 确保所有结果都没有异常
            future.result()
        except Exception as exc:
            raise exc

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