Python并发访问共享资源需加锁，因GIL无法保证复合操作原子性，多线程/协程同时读写会导致竞态条件、丢失更新；threading.Lock、asyncio.Lock等同步原语可保障数据一致性。
Python中并发访问共享资源时，必须通过同步机制保证数据一致性，否则极易出现竞态条件（race condition），导致结果不可预测。
为什么需要加锁控制共享资源
多个线程或协程同时读写同一变量、列表、字典等对象时，Python的GIL仅能保证单个字节码原子性，无法覆盖复合操作（如counter += 1，实际包含读取、计算、写入三步）。若无干预，不同线程可能基于过期值计算，造成丢失更新。
- 典型问题：多线程计数器最终值小于预期
- 常见场景：缓存更新、任务队列状态管理、配置热重载
- 协程（asyncio）同样需注意：虽然不抢占，但await会主动让出控制权，共享对象仍可能被其他协程修改
常用同步原语及适用场景
根据并发模型选择合适工具，避免过度同步影响性能。
-
threading.Lock：最基础互斥锁，适合保护临界区（如修改全局字典）。注意避免死锁——按固定顺序获取多把锁，或使用
RLock支持同一线程重复获取 - threading.Condition：配合Lock使用，实现“等待某条件成立再继续”，如生产者-消费者模式中等待队列非空
- queue.Queue：线程安全的内置队列，自动处理锁逻辑，推荐替代手动维护列表+锁
-
asyncio.Lock：协程专用锁，用法类似
threading.Lock，但必须配合await使用（如async with lock:） - concurrent.futures.ThreadPoolExecutor内部已做线程隔离，若任务间无显式共享数据，通常无需额外加锁
避免常见误区
同步机制本身不能解决所有问题，错误用法反而掩盖隐患。
- 只锁写不锁读：若读操作依赖多个字段的逻辑一致性（如银行账户余额+冻结金额），读也需加锁，或改用不可变结构+原子替换
- 锁粒度过粗：整个函数加锁会严重降低并发度，应精准包裹真正共享操作的部分
- 忘记释放锁：优先用上下文管理器（
with lock:），避免异常导致锁未释放 - 误用局部变量：函数内新建的列表/字典默认线程独立，不构成共享资源，无需加锁
- 混淆进程与线程：
multiprocessing中全局变量不共享，需用Manager或Value/Array，其同步机制与线程不同
简单示例：线程安全计数器
import threading import time❌ 不安全版本
counter = 0 def unsafeincrement(): global counter for in range(100000): counter += 1 # 非原子操作
✅ 安全版本
safe_counter = 0 lock = threading.Lock() def safe_increment(): global safecounter for in range(100000): with lock: safe_counter += 1
启动10个线程执行后，counter结果通常远小于1000000；而safe_counter恒为1000000。这直观体现了锁对一致性的保障作用。
