list的增删改操作非原子，必须加锁；仅读取在无并发修改时可不加锁，但无法保证读到最新一致状态。
直接结论：对 list 做增删改操作时，append()、extend()、pop() 等都不是原子操作，必须加锁；仅读取（如索引访问、len()）在无并发修改时可不加锁，但无法保证“读到的是最新一致状态”。
为什么 list.append() 会出错？
表面上看 list.append() 是一个函数调用，但它内部包含多个步骤：检查容量 → 扩容（可能）→ 写入新元素 → 更新长度。两个线程同时执行，可能都判断“当前长度为 5”，都写入第 6 位，结果只存了一个值，另一个被覆盖。
常见错误现象：
- 最终
len(my_list)小于预期（比如启动 10 个线程各append(1)1000 次，结果不到 10000） - 列表中出现
None或重复项（扩容竞争导致内存未初始化就写入） - 偶发
IndexError或SystemError: Negative size passed to PyList_New（极罕见，但说明底层结构已损坏）
threading.Lock 是最直接的修复方式
对所有修改 list 的代码段加同一把锁，确保任意时刻只有一个线程能进入。
实操建议：
- 锁对象必须是全局或模块级的，不能在函数内重新创建 —— 否则每个线程拿的是不同锁，完全无效
- 优先用
with lock:而非手动acquire()/release()，避免异常导致锁未释放 - 锁的粒度要覆盖整个逻辑单元，比如“先查再 append”必须包在一起，否则查完、append 前可能已被其他线程修改
示例：
import threading <p>shared_list = [] lock = threading.Lock()</p><p>def safe_append(item): with lock: shared_list.append(item) # ✅ 安全</p><p>def safe_check_and_append(item): with lock: if item not in shared_list: # ✅ 查和改在同一个临界区 shared_list.append(item)</p>
什么时候不该用 list + Lock？
当你的使用模式符合以下任一特征，list 就不是最优解：
- 频繁在头部插入/删除（
insert(0, x)/pop(0)）→ 改用collections.deque，它对两端操作更高效，但仍需加锁 - 需要按值查找+移除（
my_list.remove(x)）→ 锁住整个列表代价高，考虑改用queue.Queue（适合生产者-消费者）或带锁的set（去重场景） - 每个线程只读自己的数据副本 → 直接用
threading.local()，完全规避共享
特别注意：queue.Queue 虽线程安全，但它不是 list 的替代品 —— 它不支持随机索引、切片、in 判断等操作，强行用 list(q.queue) 绕过会破坏线程安全性。
dict 和 set 的情况类似，但更隐蔽
dict[key] = value 和 set.add() 同样是非原子的，尤其在触发哈希表扩容时极易出错。它们和 list 一样，不能靠“GIL 保平安”——GIL 只保证字节码层面单条指令原子，而扩容涉及多步 C 层内存操作。
容易被忽略的一点是：for item in my_list: 这种迭代本身不加锁，但如果循环过程中其他线程修改了列表，会触发 RuntimeError: list changed size during iteration。这不是 bug，是 Python 的保护机制；但如果你没捕获它，程序就崩了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
