直接pickle含threading.Lock的对象会失败，因其依赖操作系统原语而不可序列化；需通过__getstate__和__setstate__手动剔除锁并重建。
为什么直接 pickle 含 threading.Lock 的对象会失败
因为 threading.Lock 是不可序列化的——它底层依赖操作系统原语（如 pthread mutex），内部状态无法被 Python 的 pickle 模块捕获。尝试直接 pickle.dumps() 一个带 Lock 实例的类，会抛出 TypeError: cannot pickle '_thread.lock' object。
这不是编码问题，而是设计限制：锁本身不具备跨进程/跨时间点“重建”的语义。所以安全序列化的前提，是明确「哪些状态必须保留」「哪些必须丢弃或重置」。
用 __getstate__ 和 __setstate__ 手动控制序列化字段
这是最常用也最可控的方式。你主动告诉 pickle：忽略锁，只序列化业务数据。
- 在类中定义
__getstate__(self)，返回一个字典，**不包含**Lock类型的属性（比如self._lock） - 定义
__setstate__(self, state)，把state中的数据恢复到实例，并**重新初始化锁**（不能复用旧锁） - 注意：如果锁是通过
property或延迟初始化（self._lock = None），也要在__setstate__中补全初始化逻辑
示例：
立即学习“Python免费学习笔记（深入）”；
import threading
import pickle
<p>class Counter:
def <strong>init</strong>(self):
self.value = 0
self._lock = threading.Lock()</p><pre class="brush:php;toolbar:false;">def __getstate__(self):
# 复制当前 __dict__，但剔除锁
state = self.__dict__.copy()
del state['_lock']
return state
def __setstate__(self, state):
# 恢复数据
self.__dict__.update(state)
# 重建锁（必须！）
self._lock = threading.Lock()安全序列化
c = Counter() c.value = 42 data = pickle.dumps(c) # ✅ 不再报错 restored = pickle.loads(data) assert restored.value == 42 assert isinstance(restored._lock, threading.Lock)
序列化前手动释放锁？没必要，且危险
有人想「先 acquire() 再 release() 确保锁空闲」，这既无必要，又引入竞态风险：
-
pickle不关心锁是否被持有，只关心它能不能被序列化——而它根本不能 - 若在多线程环境中调用
__getstate__前强行release()，可能破坏原有同步逻辑 - 更糟的是：如果锁本就未被持有，
release()会直接抛RuntimeError
正确做法始终是：**跳过锁字段，不在序列化流程中碰它**。
替代方案：用可序列化的同步原语（慎选）
如果真需要「带同步语义的状态持久化」，考虑换掉 threading.Lock：
-
threading.RLock同样不可序列化，和Lock一样要排除 -
multiprocessing.Lock也不行——它封装的是 OS-level handle，同样无法 pickle - 真正可选的只有纯 Python、无系统依赖的同步结构，比如用
threading.Event+ 标志位模拟（但性能差、语义弱） - 更现实的做法是：把锁从状态中剥离，序列化时只存数据；反序列化后按需重建锁——这正是
__getstate__方案的本质
别试图让锁「变可序列化」，接受它的临时性。锁不是状态，是运行时资源。
