函数本身线程安全，但访问共享可变状态（如全局变量、类属性）会导致竞态；需用Lock同步、threading.local隔离或避免共享。
多线程调用同一个函数本身是安全的，但函数内部操作可能不安全
Python 中，多个线程调用同一个函数（比如 def process_data(x): return x * 2）完全没问题——函数对象是不可变的，代码段共享无冲突。真正出问题的是函数里访问了**共享可变状态**：全局变量、类实例属性、模块级缓存、文件句柄等。这时候不加控制就会出现竞态条件，比如计数器漏加、字典写入覆盖、列表 append 错乱。
常见错误现象：counter 本该从 0 加到 100，最后却是 87；results.append(item) 后发现 len(results) 小于预期；日志里同一时间打出两条“开始处理”，但只有一条“处理完成”。
- 纯计算型函数（无副作用、不读写外部状态）天然线程安全，无需额外措施
- 只要函数内修改了任何跨线程可见的变量，就必须考虑同步
-
threading.local()可为每个线程提供独立副本，适合保存上下文数据（如请求 ID、数据库连接）
用 threading.Lock 保护临界区是最直接的方案
当必须读写
threading.Lock 是最常用也最易理解的同步机制。它确保同一时刻只有一个线程能执行被包裹的代码块。import threadingcounter = 0 lock = threading.Lock()
def increment(): global counter with lock: # 进入临界区 temp = counter counter = temp + 1 # 模拟非原子操作
注意：锁必须作用在所有访问该资源的地方，包括读和写；否则只锁写不锁读，仍可能读到中间状态。另外，避免在锁内做耗时操作（如网络请求、大文件读写），否则会严重拖慢其他线程。
- 不要用
lock.acquire()+try/finally手动释放——容易遗漏release()，优先用with lock: - 嵌套加锁可能导致死锁，尤其在调用链深、锁粒度粗时；尽量缩小临界区范围
- 如果只是读多写少，可考虑
threading.RLock（可重入锁），但多数场景Lock更轻量
避免共享状态才是更健壮的解法
比起给处处加锁，更好的思路是让线程之间根本不共享可变数据。这往往意味着重构函数签名或调用方式。
例如，把依赖全局 config_dict 的函数改成显式传参：process(item, config)；把往全局 results 列表追加结果，改为每个线程返回独立结果，由主线程合并。
- 使用
concurrent.futures.ThreadPoolExecutor.map()时，函数应设计为纯函数，返回值由 executor 自动收集 - 若需中间状态，可用
threading.local()创建线程私有存储：local_data = threading.local()，然后在线程内设local_data.cache = {} - 对简单聚合（如求和、计数），可用
queue.Queue替代全局变量：各线程 put 结果，主线程 get 并累加
asyncio 不等于多线程，混用容易踩坑
看到“并发”就下意识用多线程，常忽略 Python 的 GIL 和实际 I/O 特性。CPU 密集任务用多线程收益极低；而真正耗时的网络/磁盘操作，用 asyncio + await 通常更高效、更易管理共享状态（因为协程在单线程内切换，没有真正的并行，很多竞争问题自然消失）。
但要注意：一旦在 async 函数里调用了阻塞式库（如旧版 requests、time.sleep），或误把 threading.Lock 用在协程中（它不是 awaitable），就会卡住整个事件循环。
- CPU 密集型任务优先考虑
multiprocessing，而非threading - 需要线程安全又想用 async？把阻塞调用用
loop.run_in_executor()托管给线程池 -
asyncio.Lock是协程友好的锁，用于await lock.acquire()场景，不能和threading.Lock混用
函数是否线程安全，从来不由“被调用多少次”决定，而取决于它是否碰了共享可变状态。最容易被忽略的，是那些看起来“只读”的操作——比如对一个全局字典做 if key in shared_dict: 再 shared_dict[key] = value，这其实是典型的检查后赋值（check-then-act）竞态，中间可能已被其他线程删掉该 key。
