为什么Python多线程在CPU密集型脚本中变慢_理解GIL锁与多进程的权衡
Python多线程在CPU密集型任务中因GIL锁导致线程排队执行，实际串行且切换开销使耗时增加10%-30%。多进程虽能并行，但需序列化传递数据，适合计算量大、参数小的任务。通过NumPy、C扩展等绕过解释器可绕开GIL限制。
Python多线程在CPU密集型任务中变慢，这不是写错了代码，而是CPython解释器在背后强制你“排队计算”——GIL让所有线程抢同一把锁，谁拿到谁算，其余只能干等着。这不是bug，而是设计上做的取舍。
原因其实很实在：线程启动、切换、争抢GIL本身就要消耗CPU时间片。而纯计算任务又不触发GIL释放——它不像requests.get()或open()那样会主动让出锁——结果多个线程在单核上反复做上下文切换，实际执行仍然是串行的。
为什么threading跑计算任务反而更耗时？
- 每100个Python字节码指令后，
GIL才有可能轮转一次，但轮转开销远大于收益 - 两个线程做同样总量的计算，耗时通常比单线程多出10%–30%。实测在
fibonacci()、sum([i**2 for i in range(10**7)])这类场景中经常出现 - 哪怕用
concurrent.futures.ThreadPoolExecutor包装再多层，也绕不开这个底层限制
multiprocessing真能解决问题吗？
能，但代价很明确：进程间不共享内存，每次传参或取结果都要走pickle序列化，数据越大越拖慢速度；启动新进程本身也有毫秒级开销。
- 适合单次计算量大、参数和返回值都很小的任务（比如对10万行数据做独立数值变换）
- 避免频繁创建
Process——用Pool或ProcessPoolExecutor复用进程会更划算 - 注意在Windows下子进程会重新导入模块，必须加上
if __name__ == '__main__':，否则会报RuntimeError: An attempt has been made to start a new process
比multiprocessing更轻量的替代方案有哪些？
不是所有计算都值得上多进程。先看看能不能“不动线程模型，只换执行体”：
NumPy/SciPy数组运算：底层由C/Fortran实现，会自动释放GIL，单线程就能吃满多核concurrent.futures.ProcessPoolExecutor+functools.partial：比裸multiprocessing更容易管理，支持超时和回调- Cython或
ctypes封装C函数：在C代码段手动调用PyThreadState_Release和PyThreadState_Swap释放GIL，适合已知的热点函数
真正容易被忽略的点：GIL不是“锁住整个程序”，而是“锁住Python字节码执行”。只要计算逻辑能下沉到不经过解释器的层面（比如向量化、C扩展、甚至subprocess.run(['rust-code'])），就自然绕开了它——优化方向不在于“怎么开更多线程”，而在于“让哪部分代码彻底不走Python解释路径”。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
AirBuddy 3 是面向 macOS 的蓝牙外设增强工具，可集中查看 AirPods、Beats 与苹果设备电量，提供快速连接、播放控制、电量提醒、桌面小组件和多台 Mac 外设接力等功能。
AirServer macOS版可把 Mac 转换为无线投屏接收端，通过 AirPlay 或 Google Cast 接收手机、平板和电脑画面，并支持多设备同时连接、高清镜像及会话录制，适合家庭娱乐、课堂教学、会议演示和应用展示。
Autodesk Maya 是面向影视、电视、动画和游戏行业的专业三维制作软件，集多边形与 NURBS 建模、角色绑定、关键帧和动作捕捉动画、Bifrost 特效模拟、材质开发及 Arnold 渲染于一体，
AirServer Windows版可把电脑变成AirPlay、Google Cast和Miracast无线投屏接收端，适合会议演示、课堂教学及家庭大屏分享。发送设备通常无需另装客户端，并可同时接收和智能排列多个镜像会话。