类属性和实例属性在并发下均不安全,必须根据访问模式显式加锁:读多写少用读写锁分离,跨实例共享需绑定对象级锁,避免全局锁或临时锁失效。

直接说结论:类属性本身不自动线程安全,实例属性更不安全;必须显式加锁,且锁粒度要匹配访问模式——不是“加个threading.Lock()就行”,而是得看你是读多写少、还是高频更新、还是跨实例共享。
为什么类属性和实例属性在并发下天然不安全
Python的类属性(如count)被所有实例共享,多个线程同时执行cls.count += 1会出错——这不是语法错误,而是+=本身是“读-改-写”三步非原子操作。实例属性(如self.value)看似隔离,但一旦多个线程操作同一个实例(比如共享一个Account对象),同样会触发竞态条件。
常见错误现象:
- 计数器最终值远小于预期(如10个线程各+10万,结果只有60万)
- 读取时拿到
None或中间态数据(比如文件读到一半被覆盖) - 属性赋值后立刻读,却返回旧值(缓存/重排序导致)
用threading.RLock()保护单个实例属性
RLock比Lock更适合属性访问场景,尤其当属性的__set__里又调用了自身__get__(比如计算属性依赖自身值),Lock会死锁,RLock允许同一线程重复进入。
实操建议:
- 每个实例独享一把锁,不要共用全局
Lock对象(否则不同实例互相阻塞) - 锁名动态生成,避免硬编码冲突,例如用
f"_{name}_lock" - 在
__get__和__set__里都检查锁是否存在,首次访问再创建,减少初始化开销 - 不要在锁内做耗时操作(如网络请求、文件读写),否则拖慢整个实例
示例关键片段:
图片提示词生成器?不止如此。 马甲系统 —— 把脑海中的画面,翻译成AI能理解的专业表达。 用得越多,它越懂你:首次需要多问几句确认方向,用久了几乎一说就懂。 用得越多,它越快:缓存机制让后续对话越来越省。 RAG进化:成功案例持续入库,越跑越聪明。 输入「新手指南」查看完整功能介绍
def __get__(self, obj, objtype=None):
if obj is None:
return self
if not hasattr(obj, self.lock_name):
setattr(obj, self.lock_name, threading.RLock())
lock = getattr(obj, self.lock_name)
with lock:
return getattr(obj, self.name, None)
并发读多写少时,别只用一把锁
如果属性90%时间被读、10%被写(比如配置缓存),用单一Lock会让所有读操作排队,吞吐骤降。这时应拆分为读锁+写锁,或直接用threading.Semaphore控制并发读数。
更轻量的做法是:读操作不加锁,仅写操作用Lock包裹,但前提是读到“脏数据”可接受(比如配置过期几秒没关系)。若必须强一致,就得上读写锁分离逻辑,或改用queue.Queue把写操作序列化到单一线程处理。
注意点:
-
threading.RLock()不解决读写竞争,它只是防同一线程死锁 - 读操作加锁后,性能可能比单线程还差,务必压测验证
- Python的GIL对纯CPU操作有保护,但对IO、sleep、C扩展无效,不能依赖GIL当锁用
跨实例共享状态时,锁必须绑定到共享对象本身
比如多个线程操作同一个Account实例的balance,锁必须挂在该实例上(如self._balance_lock),而不是定义在类里或作为模块变量。否则锁失效,变成“假同步”。
容易踩的坑:
- 把
lock = threading.Lock()写在类定义里 → 所有实例共用一把锁,过度串行 - 在方法里临时创建
Lock()→ 每次都是新锁,完全没用 - 用
@classmethod修改类属性却不加锁 → 多线程调用cls.counter += 1照样错 - 文件写入用
open(..., "w")覆盖,没锁也没临时文件 → 读进程可能读到空文件或截断内容
真正安全的文件更新,要么用os.replace()配合临时文件,要么用filelock库加系统级锁,而不是靠Python层的threading.Lock()——后者只管线程,不管进程。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










