多线程非万能,仅适用于I/O密集型耗时操作;CPython中计算密集型任务应选multiprocessing或asyncio;推荐用ThreadPoolExecutor控制并发,避免共享数据,必要时加锁;Web框架中优先用异步或后台任务而非裸线程。
API接口开发中,遇到耗时操作(比如调用第三方HTTP服务、读写文件、数据库慢查询)才考虑多线程。纯计算密集型任务用多线程反而更慢——CPython有GIL限制,此时该用multiprocessing或异步(asyncio)。简单返回JSON、做校验、查缓存这些,单线程足够快,加线程还可能引入竞态和调试困难。
别手写Thread+Queue那一套。直接上ThreadPoolExecutor,简洁、可控、自带异常传播:
ax_workers控制并发数(别设太大,一般设为CPU核数×2~5,结合I/O等待时间调整)多个线程读写同一变量(比如全局计数器、缓存字典)极易出错。解决方式有两个方向:
例如统计并发请求中某类错误次数,不要直接error_count += 1,而要:
lock.acquire()
try:
error_count += 1
finally:
lock.release()
或者更简洁:with lock: error_count += 1
Flask/FastAPI等同步框架中,在路由函数里直接起线程容易失控:请求结束但线程还在跑,可能导致资源泄漏或返回不一致。更稳妥的做法是:
基本上就这些。多线程本身不复杂,但容易忽略上下文和边界——想清楚“谁启、谁等、谁清理”,比学会start()重要得多。