17370845950

Python 单例模式实现方式与对比
最常用最可靠的单例实现是重写__new__,在内存分配阶段控制实例创建,用类变量缓存并检查实例,避免__init__多次调用问题。

Python 中 __new__ 实现单例最常用也最可靠

直接重写类的 __new__ 是 Python 里控制实例创建最底层、最稳妥的方式。它在对象内存分配阶段介入,天然避开 __init__ 多次调用的问题。

常见错误是只改 __init__ ——比如在 __init__ 里加标志位判断,但每次 MyClass() 仍会新建对象并执行 __init__,只是跳过逻辑而已,完全不是单例。

实操建议:

  • 用类变量(如 _instance)缓存首次创建的实例
  • __new__ 开头检查该变量,存在则直接返回,不调用 super().__new__
  • 注意:如果类继承自不可变类型(如 str, tuple),__new__ 必须返回正确类型,否则会报 TypeError: object.__new__(X) is not safe
  • 线程安全需额外加 threading.Lock,否则高并发下可能创建多个实例

装饰器实现单例简洁但有作用域陷阱

用函数装饰器包装类(如 @singleton)写起来短,但本质是把类变成“返回同一实例的工厂函数”,不是真正的类单例——它不改变类本身行为,只影响被装饰后的调用方式。

典型问题:

  • 子类继承被装饰的类时,Child() 会得到新实例,和父类实例无关(因为装饰器只作用于原类名)
  • 装饰器内部缓存通常用字典按类对象做 key,但如果模块被重载(如开发时热更新)、或存在多个相同名称但不同内存地址的类(如动态生成类),缓存会失效或冲突
  • 无法支持带参数的类初始化(如 MyClass(arg=1)),除非装饰器额外处理 __call__ 的参数归一化

元类实现单例灵活但容易过度设计

通过自定义元类(继承 type)在类创建时注入单例逻辑,适合需要统一管控多个类行为的场景(比如框架中要求所有 XXXService 类都必须单例)。

但它比 __new__ 更抽象,调试困难,且容易和其它元类(如 ORM 的 DeclarativeMeta)冲突。

关键点:

  • 重写元类的 __call__ 方法,在其中拦截实例化过程
  • 缓存必须放在元类实例(即类对象)上,而不是元类类变量,否则所有使用该元类的类共享一个实例
  • 若类定义了 __new__,元类的 __call__ 仍会调用它,需确保两者逻辑不打架
  • Pydantic v2+ 的 BaseModel 默认禁用自定义元类,用元类实现单例会导致 TypeError: metaclass conflict

__init__ 里做单例判断基本没用

这是新手最容易误用的方式:在 __init__ 开头加 if hasattr(self, '_inited') 并设标记。它不能阻止新对象被创建,只是让多次初始化“看起来没效果”。

后果很实际:

  • 每次 MyClass() 都分配新内存,对象 ID 不同,is 判断全失败
  • 如果有资源独占逻辑(如打开文件、连接数据库),多个实例会同时抢资源,引发异常或数据错乱
  • 垃圾回

    收压力增大,尤其在循环频繁创建的场景下(如 Web 请求中误用)
  • 单元测试中 mock 难度陡增,因为每个 new 出来的对象都是独立个体

真正需要单例的地方,控制点必须在实例诞生之前——也就是 __new__ 或更早(如元类)。其他任何地方补救,都是在修漏水的桶。