Question

在GOF的23种设计模式中，单例是最常使用的模式，通过单例模式可以保证系统中一个类只有一个实例而且该实例易于被外界访问，从而方便对实例个数的控制并节约系统资源。每当大家想要实现一个名为XxxManger的类时，往往意味着这是一个单例。在游戏编程中尤是如此，比如一个名为World的单例管理着游戏中的所有资源，包括一个名为Sun的单例，它给这个世界带来了光亮。

单例如此常见，所以有不少现代编程语言将其加到了语言特性中，如scala和falcon语言都把object定义成关键词，并用其声明单例。如在scala中，一个单例如下：

object Singleton {
  def show = println("I am a singleton")
}

object定义了一个名为Singleton的单例，它满足单例的3个需求：一是只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。对于第三点，在任何地方都可以通过调用Singleton.show()来验证。在scala中，单例没有显式的初始化操作，但并不是所有在语法层面支持单例模式的编程语言都如此，比如falcon就不一样。

object object_name [ from class1, class2 ... classN]
  property_1 = expression
  property_2 = expression
  ...
  property_N = expression
  [init block]
   function method_1( [parameter_list] )
   [method_body]
   end 
  ...
   function method_N( [parameter_list] )
   [method_body]
   end 
end 

上面是falcon语言的单例语法，[init block]能够让程序员手动控制单例的初始化代码。但是与scala和falcon相比，动态语言Python就没有那么方便了，主要原因是Python缺乏声明私有构造函数的语法元素，实例又带有类型信息。比如以下方法是不可行的：

class _Singleton(object):
     pass
Singleton = _Singleton()
del _Singleton              # 
试图删除 class 
定义
another = Singleton.__class__()     # 
没用，绕过！
print(type(another))
# 
输出
<class '__main__._Singleton'>

可见虽然把Singleton的类定义删除了，但仍然有办法通过已有实例的__class__属性生成一个新的实例。于是许多Pythonista把目光聚集到真正创建实例的方法__new__上，并做起了文章。

class Singleton(object):
   _instance = None
   def __new__(cls, *args, **kwargs):
     if not cls._instance:
      cls._instance = super(Singleton, cls).__new__(
              cls, *args, **kwargs)
     return cls._instance
if __name__ == '__main__':
   s1=Singleton()
   s2=Singleton()
   assert id(s1)==id(s2)

这个方法很好地解决了前面的问题，现在基本上可以保证“只能有一个实例”的要求了，但是在并发情况下可能会发生意。为了解决这个问题，引入一个带锁的版本。

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的正确实现。但这个方案并不完美，至少还有以下两个问题：

如果Singleton的子类重载了__new__()方法，会覆盖或者干扰Singleton类中__new__()的执行，虽然这种情况出现的概率极小，但不可忽视。

如果子类有__init__()方法，那么每次实例化该Singleton的时候，__init__()都会被调用到，这显然是不应该的，__init__()只应该在创建实例的时候被调用一次。

这两个问题当然可以解决，比如通过文档告知其他程序员，子类化Singleton的时候，请务必记得调用父类的__new__()方法；而第二个问题也可以通过偷偷地替换掉__init__()方法来确保它只调用一次。但是，为了实现一个单例，做大量的、水面之下的工作让人感觉相当不Pythonic。这也引起了Python社区的反思，有人开始重新审视Python的语法元素，发现模块采用的其实是天然的单例的实现方式。

所有的变量都会绑定到模块。

模块只初始化一次。

import机制是线程安全的（保证了在并发状态下模块也只有一个实例）。

当我们想要实现一个游戏世界时，只需简单地创建World.py就可以了。

# World.py
import Sun
def run():
     while True:
        Sun.rise()
        Sun.set()

然后在入口文件main.py里导入，并调用run()函数，看，是不是感觉这种方式最为Pythonic呢？

# main.py
import World
World.run()

注意

Alex Martelli认为单例模式要求“实例的唯一性”本身是有问题的，实际更值得关注的是实例的状态，只要所有的实例共享状态（可以狭义地理解为属性）、行为（可以狭义地理解为方法）一致就可以了。在这一思想的进一步指导下，他提出了Borg模式（在C#中又称为Monostate模式）。

  class Borg:
   __shared_state = {}
   def __init__(self):
    self.__dict__ = self.__shared_state
   # and whatever else you want in your class -- that's all!

通过Borg模式，可以创建任意数量的实例，但因为它们共享状态，从而保证了行为一致。虽然Alex的这个Borg模式仅适用于古典类（classic clasess），Python 2.2版本以后的新式类（new-style classes）需要使用__getattr__和__setattr__方法来实现（代码略），但其可开阔眼界。