先说结论
多线程操作全局变量，核心矛盾是线程安全。Python因为GIL的存在，看似"安全"，实则在非原子操作上照样会出bug。解决方案按推荐优先级排序：优先用队列（Queue）传参 → 用锁（Lock）保护 → 用线程局部存储（threading.local）隔离。
一、为什么全局变量在多线程中是个坑？
先看一个经典翻车现场：
importthreading count=0# 全局变量defworker():globalcountfor_inrange(100000):count+=1# 看似一行，实际是三步：读 → 改 → 写threads=[threading.Thread(target=worker)for_inrange(10)]fortinthreads:t.start()fortinthreads:t.join()print(count)# 期望 1000000，实际经常是 99xxxx 这种奇怪的数问题出在哪？
count += 1不是原子操作，它等价于：
temp=count# 第1步：读temp=temp+1# 第2步：改count=temp# 第3步：写两个线程可能同时读到同一个旧值，各自+1后写回，结果只增加了1。这叫竞态条件（Race Condition）。
很多人以为Python有GIL就不会有线程安全问题——GIL只保证同一时刻只有一个线程执行Python字节码，但不能保证"读-改-写"这三步不被打断。
二、四种解决方案，逐个拆解
方案1：用threading.Lock加锁（最常用）
importthreading count=0lock=threading.Lock()defworker():globalcountfor_inrange(100000):withlock:# 核心：把读-改-写包在一个锁里count+=1优点：简单直接，逻辑清晰。
缺点：锁会让线程串行执行，并发变并串，性能下降。
适用场景：写操作频繁、对性能要求不极端的场景。
方案2：用queue.Queue传参（最推荐）
不让多个线程直接改同一个全局变量，而是把结果发到队列里，由一个线程统一汇总：
importthreadingimportqueue result_queue=queue.Queue()defworker(n):# 每个线程只算自己的部分，不碰全局变量local_sum=sum(range(n))result_queue.put(local_sum)# 扔进队列threads=[threading.Thread(target=worker,args=(100000,))for_inrange(10)]fortinthreads:t.start()fortinthreads:t.join()# 主线程统一收结果total=0whilenotresult_queue.empty():total+=result_queue.get()print(total)为什么推荐？
- 线程之间零共享，根本不存在竞态
- Queue 内部自带锁，线程安全
- 符合"谁生产谁消费"的清晰分工
这是我最推荐的方案。能不共享就不共享，是并发编程的第一原则。
方案3：用threading.local做线程隔离
如果每个线程需要"自己的一份"全局变量，用threading.local：
importthreading thread_local=threading.local()defworker():# 每个线程拿到的是自己独立的副本，互不干扰thread_local.count=0for_inrange(100000):thread_local.count+=1print(f"线程{threading.current_thread().name}的结果:{thread_local.count}")threads=[threading.Thread(target=worker)for_inrange(3)]fortinthreads:t.start()fortinthreads:t.join()适用场景：每个线程需要独立维护状态（如连接对象、计数器），不需要汇总。
方案4：用concurrent.futures+as_completed（现代写法）
fromconcurrent.futuresimportThreadPoolExecutor,as_completeddefcompute(n):returnsum(range(n))withThreadPoolExecutor(max_workers=10)asexecutor:futures=[executor.submit(compute,100000)for_inrange(10)]total=sum(f.result()forfinas_completed(futures))print(total)优点：代码简洁，自动管理线程池，结果通过Future对象返回，天然隔离。
适用场景：Python 3.2+，追求代码整洁的场景。
三、常见陷阱清单
| 陷阱 | 表现 | 正确做法 |
|---|---|---|
以为+=是原子操作 | 计数结果不对 | 用锁或队列 |
| 锁的范围太大 | 性能暴跌 | 只锁必要的几行代码 |
忘了global声明 | 报UnboundLocalError | 函数内修改全局变量必须加global |
| 多线程 + 可变对象（list/dict） | append/pop 也不是原子的 | 同样需要锁保护 |
| 以为 GIL = 线程安全 | 放松警惕 | GIL不保逻辑正确性，只保字节码执行互斥 |
四、选型决策树
需要多线程共享一个变量？ ├── 不需要共享 → 用 Queue 传参 ✅（首选） ├── 每个线程要独立副本 → 用 threading.local ✅ ├── 必须共享且写多 → 用 Lock 保护 ✅ └── 只是偶尔读 → 直接读，不用锁（GIL够用）五、一句话总结
多线程操作全局变量的本质问题是"共享可变状态"。最好的解决方式不是加锁，而是消灭共享——用队列传递结果，让每个线程只管自己那一份。
如果你正在写多线程代码，回头检查一下：有没有办法把全局变量删掉，换成参数传递或队列？能删就删，这比任何锁都靠谱。
