Design Pattern: Singleton 模式

  学习是分享和合作式的!

转载请注明出处:http://blog.csdn.net/wdzxl198/article/details/9219165；

文章摘自： http://www.riabook.cn/doc/designpattern/；      

        Singleton的英文意义是独身，也就是只有一个人，应用在物件导向语言上，通常翻译作单例：单一个实例（Instance）。
很多时候，您会需要Singleton模式，例如印表机管理，您希望程式中只能有一个Print Spooler，以避免两个列印动作同时输入至印表机中；例如资料库管理，因为建立连接（Connection）物件会耗用资源，您希望程式中只能有一个 连接物件，所有其它的程式都透过这个物件来连接资料库，以避免连接物件的重复开启造成资源的耗用；例如系统程式属性档的读取，您使用单一个物件来读取属性 内容，而程式的其它部份都向这个物件要求属性资料，而不是自行读取属性资料。
      以印表机设计为例，有的设计人员会采取全域变数的方式来建立实例，并在程式中随机取用这个实例，Java虽然不支援全域变数，但透过将物件包装在一个类别之中，也有人会采用这样的写法：

   1: public class PrintSpooler {

   2:  public PrintSpooler() 

   3: {

   4:  // ....

   5:  

   6: }

   7:  public Connection 

   8: getSpooler(){

   9:  ....

  10:  

  11: }

  12: }

  13: public class GlobalObject {

  14:  private 

  15: PrintSpooler printSpooler;

  16:  public GlobalObject () 

  17: {

  18:  printSpooler = new 

  19: PrintSpooler();

  20:  

  21: ...

  22:  }

  23:  public void getPrintSpooler() 

  24: {

  25:  return 

  26: printSpooler;

  27:  }

  28: }

         无论全域变数或是以上的例子，都无法保证只产生唯一个实例，您也许会注意不犯这个错误，但与您共同工作的伙伴也许会直觉的使用建构方法来产生一个 PrintSpooler实例。
       Singleton模式可以保证一个类别只有一个实例，并提供一个访问（visit）这个实例的方法。
      一个Singleton实作即为Java中的java.lang.Runtime类别，每个Java程式执行时都有一个唯一的Runtime物件，可以透过它提供的静态方法getRuntime()方法来取得这个物件，例如：

Runtime runtime = Runtime.getRuntime();

取得Runtime物件之后，您可以透过它进行一些外部命令的执行、进行垃圾处理等等指令，您可以开启Runtime.java类别，开头的几行是这样写的：

   1:  

   2: public class Runtime {

   3:  private static Runtime currentRuntime = new Runtime();

   4:  public static Runtime getRuntime() {

   5:      return currentRuntime;

   6:  }

   7:  /** Don't let anyone else instantiate this class */

   8:  private Runtime(){}

   9:  // 以下略

  10: }

上面结构即采用Singleton模式设计，其结构使用 UML 来表即如下所示：

如上所示的，Java使用静态工厂（简单工厂模式）来取得Runtime物件，其中Runtime的建构函式被宣告为private，这样可以阻止其他人使用建构方法来建立实例；使用更一般化的表示单例的UML结构，如下图所示：

有几个实作上面结构的方法，可以在第一次需要实例时再建立物件，也就是采用所谓的Lazy Initialization：

   1: public class Singleton {

   2:  private static Singleton instance = null;

   3:  private Singleton(){

   4:  // ....

   5:  

   6:  }

   7:  public static Singleton getInstance(){

   8:      if (instance == null){

   9:          instance = new Singleton();    

  10:      }

  11:      return instance;

  12:  }

  13:  // .. 其它实作

  14: }

上面的实作适用于单执行绪的程式，在多执行绪的程式下，以下的写法在多个执行绪的竞争资源下，将仍有可能产生两个以上的实例，例如下面的情况：

   1: Thread1: if(instance == null) // true

   2: Thread2: if(instance == null) // true

   3: Thread1: instance = new Singleton(); // 产生一个实例

   4: Thread2: instance = new Singleton(); // 又产生一个实例

   5: Thread1: return instance; // 回传一个实例

   6: Thread2: return instance; // 又回传一个实例

   7:  

   8: 在多执行绪的环境下，为了避免资源同时竞争而导致如上产生多个实例的情况，加上同步（synchronized）机制：

   9:  

  10: public class Singleton {

  11:     private static Singleton instance = null;

  12:     private Singleton(){}

  13:     synchronized static public Singleton getInstance() {

  14:         if (instance == null) {

  15:             instance = new Singleton();

  16:         }

  17:         return instance;

  18:     }

  19: }

  20:  

不过这种简单的写法不适合用于像伺服器这种服务很多执行绪的程式上，同步机制会造成相当的效能低落，为了顾及Singleton、Lazy Initialization与效能问题，因而有了Double-check Locking的模式：

   1: public class Singleton {

   2:     private static Singleton instance = null;

   3:     private Singleton(){}

   4:     public static Singleton getInstance() {

   5:         if (instance == null){

   6:             synchronized(Singleton.class){

   7:                 if(instance == null) {

   8:                      instance = new Singleton();

   9:                 }

  10:             }

  11:         }

  12:         return instance;

  13:     }

  14: }

Java中Runtime类别的作法就简单多了，它舍弃了Lazy Initialization，如果您的实例初始化不是很久的话，可以用这种方式：

   1: public class Singleton {

   2:     private static Singleton instance = new Singleton();

   3:     private Singleton() {

   4:         // ....

   5:     }

   6:     public static Singleton getInstance() {

   7:         return instance;

   8:     }

   9:     // 其它实作

  10: }

Singleton本身的观念简单但应用很广，因而很多时候必须对实际环境作一些考量与调整。

Edit by Atlas

Time 2013/6/30 14:20