线程安全单例需用__new__+threading.Lock配合双重检查锁定（DCL）：外层无锁判空，内层加锁后再次判空并创建实例，确保仅一个实例；_lock必须为类变量且预初始化。
用 __new__ + threading.Lock 实现最简线程安全单例
直接在 __new__ 中加锁是最直观、可控性最强的方式。它绕过了装饰器或模块级单例的隐式行为，所有实例化逻辑集中一处，调试和验证都方便。
常见错误是只锁住“判断是否已存在实例”那段，却没把整个实例创建过程包进锁里——这会导致多个线程同时通过 if cls._instance is None 判断，然后各自执行 super().__new__(cls)，最终生成多个实例。
正确做法是：锁必须包裹从判空到赋值的完整临界区。
import threading
<p>class Singleton:
_instance = None
_lock = threading.Lock()</p><pre class="brush:php;toolbar:false;">def __new__(cls):
if cls._instance is None:
with cls._lock:
if cls._instance is None: # 双重检查
cls._instance = super().__new__(cls)
return cls._instance
立即学习“Python免费学习笔记（深入）”；
- 必须用双重检查（DCL）：外层无锁快速判断，内层加锁后再次判断，避免每次调用都抢锁
-
_lock必须是类变量，且在类定义时就初始化，不能在__new__里动态创建（否则锁对象本身就不唯一） - 不要在
__init__中做耗时操作，因为__init__每次都会执行；如需初始化逻辑，应放在__new__中首次创建后触发
为什么不用 @functools.lru_cache 或模块单例？
这两种方式看似简单，但不满足“真正单例”的语义约束：
-
@lru_cache(maxsize=1)本质是缓存返回值，它不控制类本身的构造过程；如果类有状态且依赖__init__初始化，多次调用仍会反复执行__init__，造成状态污染或资源重复申请 - 模块单例（如
singleton.py里直接写instance = MyClass()）在多线程导入场景下不安全：CPython 的模块导入本身是线程安全的，但MyClass()的执行时机不可控，若__init__有竞态逻辑，依然会出问题 - 两者都无法应对子类继承场景——子类调用时不会复用父类的缓存或模块实例
使用 __call__ 装饰器实现时的关键陷阱
用可调用类（如 SingletonMeta）作为元类或装饰器，容易忽略元类的继承传播与线程锁粒度问题。
典型错误写法：SingletonMeta 中的 _instances 字典未按类区分，导致不同子类共享同一个实例；或者锁对象是实例级而非类级，失去互斥作用。
正确要点：
- 锁必须绑定到具体类（如
cls._lock），不能共用一个全局锁，否则不同单例类之间会无谓阻塞 -
_instances字典键必须是cls，确保A和B（同继承自SingletonMeta）各自拥有独立实例 - 元类的
__call__方法中，同样需要双重检查，且锁范围覆盖整个实例创建路径
实际项目中更推荐“显式工厂函数”替代硬编码单例
真正在业务代码里，硬编码单例常带来测试困难、依赖隐藏、生命周期难管理等问题。多数场景下，用一个带锁的工厂函数更灵活：
_db_instance = None _db_lock = threading.Lock() <p>def get_database(): global _db_instance if _db_instance is None: with _db_lock: if _db_instance is None: _db_instance = DatabaseConnection() return _db_instance
这样做的好处：
- 实例化逻辑完全暴露，便于打桩、替换、延迟初始化
- 锁对象和实例变量命名清晰，不依赖类机制，减少元编程心智负担
- 可以轻松支持“按配置决定是否单例”，比如测试环境每次返回新实例，生产环境才走单例路径
真正的难点不在“怎么写单例”，而在于确认“是否真的需要单例”。数据库连接池、日志器、配置管理器这些有明确全局唯一语义的对象才适合；普通业务对象强行套单例，往往只是掩盖了设计缺陷。
