max_workers 控制线程池中最多同时存活的 worker 线程数，非瞬时并发任务数；超量任务排队等待，不被拒绝；设为 None 时默认约 min(32, cpu_count+4)，I/O 密集场景易引发资源争抢。
ThreadPoolExecutor 的 max_workers 参数到底控制什么？
max_workers 控制的是线程池中**最多同时存活的 worker 线程数**，不是“同一时刻最多执行几个任务”。当提交的任务数超过 max_workers，多余任务会排队等待空闲线程，而不是被拒绝或丢弃。
- 设为
None（默认）时，值约为min(32, os.cpu_count() + 4)，对 I/O 密集型任务通常偏大，容易造成系统级资源争抢（如文件句柄、HTTP 连接耗尽） - 设为
1时，所有任务串行执行，失去并发意义；但可用于调试或强制顺序执行 - 实际并发请求数还受下游服务限流、网络连接池（如
aiohttp或requests.adapters.HTTPAdapter）影响，max_workers只是上层节流阀
为什么设置了 max_workers 却还是触发了 ConnectionError: Too many open files？
常见于高频 HTTP 请求场景。根本原因不是 ThreadPoolExecutor 本身开太多线程，而是每个线程里用 requests 发起请求后，未显式关闭响应或复用会话，导致 socket 文件描述符堆积。
- 错误写法：
requests.get(url)每次都新建连接，响应体读完后若没调用.close()或用with，连接可能延迟释放 - 正确做法：复用
requests.Session，并配置连接池大小，例如session.mount('https://', requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=10)) -
max_workers=10+pool_maxsize=10是较安全的组合；若设max_workers=50但pool_maxsize=10，其余 40 个线程会在连接池满时阻塞等待，而非报错
submit() 和 map() 在控制并发行为上有啥区别？
两者都尊重 max_workers，但任务调度和异常传播机制不同。
-
submit(func, *args)立即返回Future对象，适合需要单独处理每个任务结果或异常的场景；可随时调用future.result(timeout=...)阻塞获取，超时抛concurrent.futures.TimeoutError -
executor.map(func, iterable)返回迭代器，按输入顺序 yield 结果；但它会**预先启动所有任务**（即使你只取前几个），只要线程池有空位就塞进去 —— 所以如果iterable是生成器且含百万项，内存不会爆，但任务提交是“贪心”的 - 若某次
map调用中某个任务抛异常，该异常会在你遍历到对应位置时才 raise，不是提交时；而submit的异常需显式在.result()中捕获
如何动态调整运行中的 ThreadPoolExecutor 并发数？
不能。Python 标准库的 ThreadPoolExecutor **不支持运行时修改 max_workers**。实例化后该值只读，内部线程池结构已固定。
立即学习“Python免费学习笔记（深入）”；
- 强行替换
executor._max_workers属于私有属性操作，无效且危险；线程池管理逻辑（如_adjust_thread_count）不响应此变更 - 需要动态伸缩时，只能停掉旧 executor，新建一个不同
max_workers的实例，并重新提交待处理任务 - 若追求弹性，建议换用更底层方案：直接管理
threading.Thread列表 + 任务队列（queue.Queue），或使用第三方库如loky/processpoolexecutor的扩展版本（但注意它们也不解决线程池热调问题）
真正难控的从来不是数字本身，而是任务粒度与外部依赖的隐式耦合——比如一个“小任务”内部做了三次重试+日志落盘+回调通知，它实际占用线程的时间远超预期。
