前言

今天在群里讨论时讨论到了单例模式,这应该是大家最熟悉的一种设计模式了。

简单而言,单例模式就是保证某个实例在项目的整个生命周期中只存在一个,在项目的任意位置使用,都是同一个实例。

SRE实战 互联网时代守护先锋,助力企业售后服务体系运筹帷幄!一键直达领取阿里云限量特价优惠。

单例模式虽然简单,但还是有些门道的,而少有人知道这些门道。

边界情况

Python中实现单例模式的方法很多,我以前最常使用的应该是下面这种写法。

class Singleton(object): _instance = None def __new__(cls, *args, **kw): if cls._instance is None: cls._instance = object.__new__(cls, *args, **kw) return cls._instance 复制代码

这种写法有两个问题。

1.单例模式对应类实例化时无法传入参数,将上面的代码扩展成下面形式。

class Singleton(object): _instance = None def __new__(cls, *args, **kw): if cls._instance is None: cls._instance = object.__new__(cls, *args, **kw) return cls._instance def __init(self, x, y): self.x = x self.y = y s = Singleton(1,2)

此时会抛出TypeError: object.__new__() takes exactly one argument (the type to instantiate)错误

2.多个线程实例化Singleton类时,可能会出现创建多个实例的情况,因为很有可能多个线程同时判断cls._instance is None,从而进入初始化实例的代码中。
3.除了单例模式问题。这里顺便免费送大家一套2020最新python入门到高级项目实战视频教程,可以去小编的Python交流.裙 :七衣衣九七七巴而五(数字的谐音)转换下可以找到了,还可以跟老司机交流讨教!

基于同步锁实现单例

先考虑上述实现遇到的第二个问题。

既然多线程情况下会出现边界情况从而参数多个实例,那么使用同步锁解决多线程的冲突则可。

import threading # 同步锁 def synchronous_lock(func): def wrapper(*args, **kwargs): with threading.Lock(): return func(*args, **kwargs) return wrapper class Singleton(object): instance = None  @synchronous_lock def __new__(cls, *args, **kwargs): if cls.instance is None: cls.instance = object.__new__(cls, *args, **kwargs) return cls.instance 复制代码

上述代码中通过threading.Lock()将单例化方法同步化,这样在面对多个线程时也不会出现创建多个实例的情况,可以简单试验一下。

def worker(): s = Singleton() print(id(s)) def test(): task = [] for i in range(10): t = threading.Thread(target=worker) task.append(t) for i in task: i.start() for i in task: i.join() test() 复制代码

运行后,打印的单例的id都是相同的。

更优的方法

加了同步锁之后,除了无法传入参数外,已经没有什么大问题了,但是否有更优的解决方法呢?单例模式是否有可以接受参数的实现方式?

阅读Python官方的wiki(wiki.python.org/moin/Python…

def singleton(cls): cls.__new_original__ = cls.__new__  @functools.wraps(cls.__new__) def singleton_new(cls, *args, **kwargs): it = cls.__dict__.get('__it__') if it is not None: return it cls.__it__ = it = cls.__new_original__(cls, *args, **kwargs) it.__init_original__(*args, **kwargs) return it cls.__new__ = singleton_new cls.__init_original__ = cls.__init__ cls.__init__ = object.__init__ return cls @singleton class Foo(object): def __new__(cls, *args, **kwargs): cls.x = 10 return object.__new__(cls) def __init__(self, x, y): assert self.x == 10 self.x = x self.y = y 复制代码

上述代码中定义了singleton类装饰器,装饰器在预编译时就会执行,利用这个特性,singleton类装饰器中替换了类原本的__new____init__方法,使用singleton_new方法进行类的实例化,在singleton_new方法中,先判断类的属性中是否存在__it__属性,以此来判断是否要创建新的实例,如果要创建,则调用类原本的__new__方法完成实例化并调用原本的__init__方法将参数传递给当前类,从而完成单例模式的目的。

这种方法让单例类可以接受对应的参数但面对多线程同时实例化还是可能会出现多个实例,此时加上线程同步锁则可。

def singleton(cls): cls.__new_original__ = cls.__new__  @functools.wraps(cls.__new__) def singleton_new(cls, *args, **kwargs): # 同步锁 with threading.Lock(): it = cls.__dict__.get('__it__') if it is not None: return it cls.__it__ = it = cls.__new_original__(cls, *args, **kwargs) it.__init_original__(*args, **kwargs) return it cls.__new__ = singleton_new cls.__init_original__ = cls.__init__ cls.__init__ = object.__init__ return cls 复制代码

是否加同步锁的额外考虑

如果一个项目不需要使用线程相关机制,只是在单例化这里使用了线程锁,这其实不是必要的,它会拖慢项目的运行速度。

阅读CPython线程模块相关的源码,你会发现,Python一开始时并没有初始化线程相关的环境,只有当你使用theading库相关功能时,才会调用PyEval_InitThreads方法初始化多线程相关的环境,代码片段如下(我省略了很多不相关代码)。

static PyObject * thread_PyThread_start_new_thread(PyObject *self, PyObject *fargs) { PyObject *func, *args, *keyw = NULL; struct bootstate *boot; unsigned long ident; // 初始化多线程环境,解释器默认不初始化,只有用户使用时,才初始化。 PyEval_InitThreads(); /* Start the interpreter's thread-awareness */ // 创建线程 ident = PyThread_start_new_thread(t_bootstrap, (void*) boot); // 返回线程id return PyLong_FromUnsignedLong(ident); }

为什么会这样?

因为多线程环境会启动GIL锁相关的逻辑,这会影响Python程序运行速度。很多简单的Python程序并不需要使用多线程,此时不需要初始化线程相关的环境,Python程序在没有GIL锁的情况下会运行的更快。

如果你的项目中不会涉及多线程操作,那么就没有使用有同步锁来实现单例模式。​另外出单例模式问题。这里顺便免费送大家一套2020最新python入门到高级项目实战视频教程,可以去小编的Python交流.裙 :七衣衣九七七巴而五(数字的谐音)转换下可以找到了,还可以跟老司机交流讨教!

结尾

互联网中有很多Python实现单例模式的文章,你只需要从多线程下是否可以保证单实例以及单例化时是否可以传入初始参数两点来判断相应的实现方法则可。

本文的文字及图片来源于网络加上自己的想法,仅供学习、交流使用,不具有任何商业用途,版权归原作者所有,如有问题请及时联系我们以作处理。

扫码关注我们
微信号:SRE实战
拒绝背锅 运筹帷幄