线程池大小不能简单设为CPU核数的2倍，需按任务类型区分：CPU密集型用min(核心数,并发请求数)，I/O密集型需压测确定；注意内存占用、GIL切换、线程安全等问题。

线程池大小设成 CPU 核数的 2 倍就对了？

不对。硬套“2×CPU 核数”在 I/O 密集型场景下会严重拖慢吞吐，比如大量 httpx.get() 或数据库查询；而在纯计算任务里又可能引发频繁上下文切换。关键看任务类型：CPU 密集型用 min(核心数, 并发请求数)，I/O 密集型得靠压测反推。

实操建议：

• 先用 psutil.cpu_count(logical=False) 拿到物理核数，别直接用 os.cpu_count()
• I/O 类任务（如调第三方 API）初始线程数从 10 起步，逐步加到 50，观察 ThreadPoolExecutor.submit() 的平均延迟和失败率
• 避免把数据库连接池大小和线程池混为一谈——前者控制连接数，后者控制并发执行单元，两者不等价

用 concurrent.futures.ThreadPoolExecutor 还是插件？

绝大多数情况用标准库 ThreadPoolExecutor 就够了，它稳定、无额外依赖、API 清晰。所谓“线程池插件”（如 threadpoolctl 或某些 Web 框架封装）往往只是加了监控或自动伸缩逻辑，并不改变底层行为。

实操建议：

• 别为了“高级感”引入 threadpoolctl——它只管 OpenMP/BLAS 线程，对 Python 自己的 ThreadPoolExecutor 完全无效
• Django/Flask 项目里看到的 “线程池中间件”，本质是把 ThreadPoolExecutor 实例挂到 app.state 或全局变量，自己写就行
• 需要动态调参？直接存一个 executor 实例，用 executor.shutdown(wait=False) + 新建实例替换，别试图热改已运行的池

max_workers 设太小会超时，设太大内存爆掉？

会。每个线程默认占 8MB 栈空间（Linux 下可查 /proc//limits 的 Stack size），1000 个线程就是 8GB 内存，还没算任务对象开销。同时，过多线程会让 GIL 切换更频繁，实际吞吐反而下降。

实操建议：

• 上线前用 tracemalloc 抓住单次任务内存峰值，再乘以预期并发数，留 30% 余量定 max_workers
• 给 submit() 加 timeout 参数，否则一个卡死的任务会占住整个线程，导致后续任务排队饿死
• 遇到 BrokenThreadPool 或 RuntimeError: can't start new thread，优先检查是否漏调 shutdown()，而不是盲目扩大小

为什么用了线程池，_thread_handling 相关错误还在？

因为 _thread_handling 不是线程池的问题，而是你在非线程安全上下文里误用了共享状态。典型如：多个线程共用一个未加锁的 dict 计数器、或在 Flask 的 g 对象里存可变数据。

实操建议：

• 查错误栈里是否出现 KeyError、AttributeError 或 RuntimeError: dictionary changed size during iteration —— 这些都是典型的竞态信号
• 用 threading.local() 替代全局变量，每个线程拿到独立副本，比手动加 Lock 更轻量
• Web 框架中慎用 app.config 存运行时状态，它不是线程隔离的；改用 flask.g 或 contextvars.ContextVar

线程池本身不制造竞态，但它会放大你代码里原本被低并发掩盖的线程安全漏洞。问题不在池子，在用池子的人有没有意识到“共享即风险”。