竞态条件源于多线程同时读写共享数据且缺乏同步控制，导致结果依赖执行时序；GIL不保证复合操作原子性，常见如counter+=1、检查再设置等场景易触发，引发逻辑错误且难以复现。
竞态条件（Race Condition）在 Python 多线程中，本质上是因为多个线程**同时读写共享数据且缺乏同步控制**，导致最终结果依赖于线程执行的时序，从而不可预测。
共享变量未加保护是直接诱因
当多个线程访问同一个全局变量、类实例属性或可变对象（如 list、dict）时，如果其中至少有一个线程在修改它，而没有使用锁（threading.Lock）、信号量或原子操作，就极易触发竞态。例如：
两个线程同时执行 counter += 1（等价于读取、加 1、写回三步），可能都读到旧值，各自加 1 后写回，结果只增加了一次而非两次。
GIL 并不能防止所有竞态
Python 的全局解释器锁（GIL）仅保证同一时刻只有一个线程执行 Python 字节码，但它**不保证复合操作的原子性**。像 list.append() 或 dict[key] = value 这类操作，在字节码层面仍由多条指令组成，中间可能被切换。尤其在 I/O 等待、显式调用 time.sleep() 或大量计算触发 GIL 释放时，线程切换更频繁，竞态窗口更大。
立即学习“Python免费学习笔记（深入）”；
看似安全的操作也可能出问题
有些操作在单线程下绝对可靠，放到多线程里就危险。比如：
- 检查再设置模式：if not flag: flag = True —— 两个线程几乎同时通过 if 判断，都会设为 True；
- 基于列表长度做判断：if len(my_list) > 0: item = my_list.pop() —— 中间可能被另一个线程 pop 掉，导致 IndexError；
- 使用非线程安全的模块对象（如某些第三方库的缓存、连接池）。
调试困难加剧了风险
竞态条件通常不会报错，而是产生逻辑错误：数值算错、数据丢失、状态不一致。它往往只在高并发、压力大或特定调度顺序下偶然复现，本地测试容易漏掉，上线后才暴露，排查成本很高。
避免的关键不是避免多线程，而是识别共享状态、明确临界区，并用 Lock、RLock、queue.Queue 等工具做最小粒度的同步。不复杂但容易忽略。
