现在的位置: 首页 > 综合 > 正文

单例模式[转]

2013年09月16日 ⁄ 综合 ⁄ 共 4139字 ⁄ 字号 评论关闭

以下内容转载自:http://www.yesky.com/60/1723060.shtml

java模式之单例模式:

      作为对象的创建模式[GOF95], 单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。这个类称为单例类。

      注:本文乃阎宏博士的《Java
与模式》一书的第十五章。
特点:

  1. 一个类只能有一个实例
  2. 自己创建这个实例
  3. 整个系统都要使用这个实例

     例: 在下面的对象图中,有一个"单例对象",而"客户甲"、"客户乙" 和"客户丙"是单例对象的三个客户对象。可以看到,所有的客户对象共享一个单例对象。而且从单例对象到自身的连接线可以看出,单例对象持有对自己的引用。

 

 

 

以下内容转载自:http://www.blogjava.net/asdtiang/archive/2011/03/15/346289.html

 

      Singleton 模式的宗旨在于确保某个类只有一个实例,别且为之提供一个全局访问点。为了防止其他工作人员实例化我们的类,可以为该类创建唯一一个构造器,并将构造器的可见设置为私有。值得注意的是,如果我们创建了其他的非私有的构造器,或者根本没有为该类提供构造器,那么其他人员还是能实例化我们的类。 如果不希望提前创建单例对象,我们可以等到第一次使用该单例对象的时候在创建它,即滞后初始化。滞后初始化单例对象有两个理由:

  1. 也许在静态初始化时间,你没有关于如何初始化单例对象的足够信息。
  2. 选择滞后初始化单例的目的也许为了等待资源,诸如数据库连接,尤其是在某些特定会话中不需要这个单例的应用程序中。

      如果在多线程环境中对单例采用滞后初始化,那么我们必须小心防止多个线程同时初始化该

通常单例模式在Java语言中,有两种构建方式:

  • 懒汉方式:指全局的单例实例在第一次被使用时构建。延迟初始化。
  • 饿汉方式:指全局的单例实例在类装载时构建。 急切初始化。

      在懒汉单例中,单线程是没有问题的,但多线程时就会有可能出现两个或者以上的Singletion2实例的情况。
      例如:线程1在判断instance==null为真,扫行new操作时,在执行new操作之前,判断为真之后,线程2正好执行判断操作,这时
instance还为null.因此,线程2也会执行new操作。以此类推,在高并发下面,就可能存在两个或者以上的实例。显然,这是不正确的。因此需加上synchronized


 

以下七种方法转载自:http://cantellow.iteye.com/blog/838473

 

第一种(懒汉,线程不安全):



 

第二种(懒汉,线程安全):



 

第三种(饿汉):


      这种方式基于
classloder
机制避免了多线程的同步问题,不过,
instance
在类装载时就实例化,虽然导致类装载的原因有很多种,在单例模式中大多数都是调用
getInstance
方法,
 
但是也不能确定有其他的方式(或者其他的静态方法)导致类装载,这时候初始化
instance
显然没有达到
lazy loading
的效果。

 

第四种(饿


汉,变种):


      表面上看起来差别挺大,其实更第三种方式差不多,都是在类初始化即实例化instance。

 

第五种(静态内部类):


      这种方式同样利用了
classloder
的机制来保证初始化
instance
时只有一个线程,它跟第三种和第四种方式不同的是(很细微的差别):第三种和第四种方式是只要
Singleton
类被装载了,那么
instance
就会被实例化(没有达到
lazy loading
效果),而这种方式是
Singleton
类被装载了,
instance
不一定被初始化。因为
SingletonHolder
类没有被主动使用,只有显示通过调用
getInstance
方法时,才会显示装载
SingletonHolder
类,从而实例化
instance
。想象一下,如果实例化
instance
很消耗资源,我想让他延迟加载,另外一方面,我不希望在
Singleton
类加载时就实例化,因为我不能确保
Singleton
类还可能在其他的地方被主动使用从而被加载,那么这个时候实例化
instance
显然是不合适的。这个时候,这种方式相比第三和第四种方式就显得很合理。

 

第六种(枚举):


      这种方式是Effective Java作者Josh Bloch
提倡的方式,它不仅能避免多线程同步问题,而且还能防止反序列化重新创建新的对象,可谓是很坚强的壁垒啊,不过,个人认为由于1.5中才加入enum特
性,用这种方式写不免让人感觉生疏,在实际工作中,我也很少看见有人这么写过。

 

第七种(双重校验锁):


      这个是第二种方式的升级版,俗称双重检查锁定,详细介绍请查看:http://www.ibm.com/developerworks/cn/java/j-dcl.html

在JDK1.5之后,双重检查锁定才能够正常达到单例效果。

 

总结

     有两个问题需要注意:

     1.如果单例由不同的类装载器装入,那便有可能存在多个单例类的实例。假定不是远端存取,例如一些servlet
容器对每个servlet
使用完全不同的类装载器,这样的话如果有两个servlet
访问一个单例类,它们就都会有各自的实例。

     2.如果Singleton
实现了java.io.Serializable
接口,那么这个类的实例就可能被序列化和复原。不管怎样,如果你序列化一个单例类的对象,接下来复原多个那个对象,那你就会有多个单例类的实例。

      对第一个问题修复的办法是:

      对第二个问题修复的办法是:

      对我来说,我比较喜欢第三种和第五种方式,简单易懂,而且在JVM层实现了线程安全(如果不是多个类加载器环境),一般的情况下,我会使用第三种方
式,只有在要明确实现lazy
loading效果时才会使用第五种方式,另外,如果涉及到反序列化创建对象时我会试着使用枚举的方式来实现单例,不过,我一直会保证我的程序是线程安全
的,而且我永远不会使用第一种和第二种方式,如果有其他特殊的需求,我可能会使用第七种方式,毕竟,JDK1.5已经没有双重检查锁定的问题了。

 

========================================================================

 

 superheizai
同学总结的很到位:

      不过一般来说,第一种不算单例,第四种和第三种就是一种,如果算的话,第五种也可以分开写了。所以说,一般单例都是五种写法。懒汉,恶汉,双重校验锁,枚举和静态内部类。

抱歉!评论已关闭.