设计模式之Singleton(单态)

单态定义:
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存在。

在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。

还有, singleton能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

另外方面，Singleton也能够被无状态化。提供工具性质的功能，

Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。

如何使用?
一般Singleton模式通常有几种形式:

public class Singleton {

　　private Singleton(){}

　　//在自己内部定义自己一个实例，是不是很奇怪？
　　//注意这是private 只供内部调用

　　private static Singleton instance = new Singleton();

　　//这里提供了一个供外部访问本class的静态方法，可以直接访问　　
　　public static Singleton getInstance() {
　　　　return instance; 　　
　　 } 
} 

 

第二种形式:

public class Singleton { 
　　private static Singleton instance = null;

　　public static synchronized Singleton getInstance() {

　　if (instance==null)
　　　　instance＝new Singleton();
　　return instance; 　　} 

} 

 

使用Singleton.getInstance()可以访问单态类。

上面第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。

注意到lazy initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。关于lazy initialization的Singleton有很多涉及double-checked locking (DCL)的讨论，有兴趣者进一步研究。

一般认为第一种形式要更加安全些。

使用Singleton注意事项：
有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下：

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。

总之：如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术。

 

最近我听到了这样一种说法：Singleton模式在多线程环境下存在性能问题。并且，这就成了Singleton模式的一个罪状：因为Singleton在多线程底下有性能问题，因为J2EE是多线程的，所以J2EE底下不应该用Singleton模式。现在我来帮这些擅长过度省略的高手们补补课：Singleton模式，究竟在怎样的情况下才有性能陷阱？

第一个问题，Singleton模式在多线程环境为何遭遇困境？答案是，采用lazy initialization策略时，如果没有合理的同步（synchronize），各个线程得到的实例可能不是同一个。详情可以参考JavaWorld 2001年的文章：When Is A Singleton Not A Singleton。（某些同志连这篇文章都没听说过，居然也可以抱怨说“找不到这方面的英文资料”，恩，我们说话恐怕还是谦虚谨慎点好。）

public class MyClass {  
          private static MyClass  _instance;  
          public static MyClass getInstance() {   
                     if(_instance != null) {      
                               _instance = new MyClass();    
                     }    
                   return _instance; 
           } 
}

 如果有两个线程同时调用MyClass.getInstance()方法，就有可能造成MyClass的构造子被调用两次。所以我们需要同步――准确说，恰当的同步。在C++里面有一种常见的Singleton实现策略叫Double Checked Locking idiom（http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton_p.html，listing 6），但这种实现策略在Java中不生效（这是由于JVM的本性造成的，详情请看这篇文章：http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ），因此如果要在Java中实现lazy initialization策略的Singleton，你就必须采取保守的同步策略，也就是：

public static [b]synchronized[/b] MyClass getInstance() {  ...} 

 如果采取保守的同步策略（将整个getInstance()方法同步），多个线程需要获得Singleton实例时就必须在getInstance()方法上排队等待。这就是传说中的“Singleton模式的性能问题”。现在我要提问了：这种性能问题在什么情况下才会出现？

答案就摆在你面前：只有采用lazy initialization策略时，才会存在这样的性能问题。那么如果放弃lazy initialization策略、改用eager initialization策略（即：预先创建好Singleton实例），Singleton模式还会存在这样的性能问题吗？我们把上面的例子改成eager initialization策略看看：

public class MyClass {  
       private static MyClass _instance = [b]new MyClass();  
       public static MyClass getInstance() {
                      return _instance;  
       } 
}

 我请问，这样的一个Singleton难道还会有什么“性能问题”吗？它付出的代价是更长的初始化时间，获得的收益则是更快并且线程安全的实例获得，而这正是Spring容器对其管理的组件的默认策略。其实这个问题早已有了定论，请看http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton_p.html这篇文章的listing 1和listing 2，Singleton模式的两种正确的实现策略早在2001年就已经讨论清楚了。

作为结论，我提醒某些善于过度简化乃至以讹传讹的高手们：请不要简单地说一句“Singleton模式有性能问题”了事。完整的说法应该是，当采用Lazy Initialization策略时，如果需要经常地获取Singleton实例，则Singleton模式中用于获取实例的方法有可能成为性能瓶颈；如果条件允许采用Eager Initialization策略，则Singleton模式不会带来任何额外的性能开销――如果考虑管理对象池或是新建对象实例的性能开销，Singleton模式能够提升系统的性能。