题目重点：从 CPython 默认 GIL 的字节码执行约束出发，比较 I/O 线程、进程池、释放 GIL 的扩展和可选 free-threaded 构建，并纠正‘Python 线程一律不能并行’。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 默认讨论通常带 GIL 的 CPython 构建，不把其机制外推到所有 Python 实现或可选 free-threaded 构建。
- 以独立 CPU 计算任务和等待网络 I/O 的任务作训练对照，题目未指定任务。
解题路线
- 先答定义：在默认 CPython 构建中，GIL 使一个进程内同一时刻只有一个线程执行 Python 字节码；它简化解释器对象管理，但不是应用数据竞态的通用锁。
- 区分负载：I/O 等待期间线程可让出执行，多个网络请求能交错推进；纯 Python CPU 密集循环用更多线程通常得不到多核字节码并行，还可能增加切换开销。
- 若要多核 CPU 计算，可考虑多进程与序列化/共享内存成本，或确认数值扩展是否释放 GIL。若有可选 free-threaded CPython 构建，需确认 build、运行时 GIL 状态和第三方扩展兼容性；不能仅凭版本号断言 GIL 已关闭。
- 无论 GIL 状态如何，多步骤共享状态更新仍要按需要加锁、队列或隔离；通过真实吞吐、CPU 利用率和正确性测试验证选型。
手动走一遍
训练例：100 个网络请求各等待约 100ms，线程池能重叠等待，但仍受连接池/服务端限流影响；100 个纯 Python 数字循环若各占 100ms CPU，默认 GIL 下线程并不会理想地变成 100ms 总耗时。改进程池前先量任务粒度与数据搬运成本。这里的耗时仅是示意，非面经测试数据。
规模与取舍
GIL 不改变单任务算法的渐近复杂度。并发总耗时受任务可并行比例、线程/进程管理、I/O 等待、序列化和调度影响；默认 CPython 的纯 Python CPU 工作难由同进程线程数线性缩短。
易错点与追问
容易失分的边界
- 说 GIL 禁止任何线程并发或所有 Python 实现都相同。
- 把 GIL 当业务变量的安全保证，遗漏复合操作的竞态。
- 忽略 free-threaded 构建与扩展可能重新启用 GIL 的现状。
- 不分 CPU 与 I/O 工作，直接宣称线程或进程必胜。
继续深挖
- 如何测程序时间花在 Python 字节码、I/O 或 native 扩展？
- free-threaded 构建下如何验证第三方扩展与共享容器安全？
- 进程池的 IPC 成本何时压过并行收益？
技术参考
- Python threading 官方文档：技术参考：默认 CPython GIL、CPU 与 I/O 线程取舍。
- Python free-threading 官方文档：技术参考：可选构建、运行时状态及扩展兼容性。
