我知道的一种在 python 中 Singleton mode 的实现如下:
class Foo: pass
def instance():
global inst
try:
inst
except:
inst = Foo ()
return inst
该实现的优点就是简单和直观,但缺点也同样明显:
第 2 点是相当严重的一个缺陷,如果你用了上面的代码,那只能祈祷不要有 1 个以上的实例出现(虽然几率较低,但还是有可能),否则就会出现稀奇古怪的问题。
一个稍微好些实现如下:
class Singleton(object):
objs = {}
def __new__(cls, *args, **kv):
if cls in cls.objs:
return cls.objs[cls]
cls.objs[cls] = object.__new__(cls)
这个实现解决了第一个缺点,那些只需要一个实例的类想实现 Singleton mode ,只要从 Singleton 类继承即可,无论在代码的哪里实例化该类,都只存在该类的一个实例。
为了解决第 2 个缺点,一个进化的版本出现了,如下:
class Singleton(object):
objs = {}
objs_locker = threading.Lock()
def __new__(cls, *args, **kv):
if cls in cls.objs:
return cls.objs[cls]
cls.objs_locker.acquire()
try:
if cls in cls.objs: ## double check locking
return cls.objs[cls]
cls.objs[cls] = object.__new__(cls)
finally:
cls.objs_locker.release()
是不是看着眼熟,对了,这就是在 Singleton mode 中经典的双检查锁机制,该机制确保了在并发环境下 Singleton mode 的正确实现。
到此为止,上面提到的 2 个缺点都被进化后的代码解决了,看上去已经很完美了,但是故事到此还没有结束,不知道你是否看出来改进后的代码还有什么问题吗?
再继续之前,先介绍关于 __new__ 和 __init__ 的基础知识, Python 的经典类和新式类都支持 __init__ 函数,但只有新式类支持 __new__ 函数,在一个新式类创建过程中, Python 解释器会先调用该类的 __new__ 函数 创建 实例,然后在调用 __init__ 函数 初始化 这个实例,如果这些函数不存在,就会调用 Python默认提供的版本,但如果用户提供了这些函数的实现,就会调用用户实现的版本。
上面改进后的代码也存在 2 个问题:
为了解决 __init__ 被多次调用的问题,一个更高级(同时也更复杂)的版本如下:
class Singleton(object):
objs = {}
objs_locker = threading.Lock()
def __new__(cls, *args, **kv):
if cls in cls.objs:
return cls.objs[cls]['obj']
cls.objs_locker.acquire()
try:
if cls in cls.objs: ## double check locking
return cls.objs[cls]['obj']
obj = object.__new__(cls)
cls.objs[cls] = {'obj': obj, 'init': False}
setattr(cls, '__init__', cls.decorate_init(cls.__init__))
finally:
cls.objs_locker.release()
@classmethod
def decorate_init(cls, fn):
def init_wrap(*args):
if not cls.objs[cls]['init']:
fn(*args)
cls.objs[cls]['init'] = True
return
return init_wrap
看到这里,你可能会想:一件简单的事情,有必要搞的那么复杂么?
我的回答是:根据情况而定。
有得必有失
简单的实现,代码逻辑清晰,维护量小,修改也很简单,但是应用环境受限(上面前 2 点所述),并且一些初始化工作交由客户来完成(调用 instance 函数),在小系统中这不是问题,但在一个大系统中,这会变成一个很明显的负担(特别是在实例化函数命名不统一的时候)。
复杂的实现,所有创建操作在一处完成,不对环境作假设,不给客户带来任何负担,像普通类一样使用,最重要的是将单件创建(基类)和业务代码(继承类)分开,划分清晰;缺点是代码复杂,不好维护和修改,需要一定的 Python 高级语言特性。