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内部已做线程隔离，若任务间无显式共享数据，通常无需额外加锁

避免常见误区

同步机制本身不能解决所有问题，错误用法反而掩盖隐患。

立即学习“Python免费学习笔记（深入）”；

• 只锁写不锁读：若读操作依赖多个字段的逻辑一致性（如银行账户余额+冻结金额），读也需加锁，或改用不可变结构+原子替换
• 锁粒度过粗：整个函数加锁会严重降低并发度，应精准包裹真正共享操作的部分
• 忘记释放锁：优先用上下文管理器（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。这直观体现了锁对一致性的保障作用。