单例模式总结
时间:2010-03-09 来源:mcuflower
单例模式总结
单例模式(Singleton)
1) 单例类只能有一个实例
2) 单例类必须自己创建自己的唯一的实例
3) 单例类必须给所有其他对象提供这一实例
1、 饿汉式单例类:
public class EagerSingleton{
private static final EagerSingleton m_instance=new EagerSingleton();
private EagerSingleton(){
}
public static EagerSingleton getInstance(){
return m_instance;
}
}
2、 懒汉式单例式:
public class LazySingleton{
private static LazySingleton m_instance=null;
private LazySington(){
}
synchronized public static LazySingleton getInstance(){
if(m_instance==null){
m_instance=new LazySingleton();
}
return m_instance;
}
}
在上面给出懒汉式单例类实现里对静态工厂方法使用了同步化,以处理多线程环境。有些设计师在这里
建议使用所谓的"双重检查成例".必须指出的是,"双重检查成例"不可以在Java 语言中使用。不十分熟
悉的读者,可以看看后面给出的小节。
同样,由于构造子是私有的,因此,此类不能被继承。饿汉式单例类在自己被加载时就将自己实例
化。即便加载器是静态的,在饿汉式单例类被加载时仍会将自己实例化。单从资源利用效率角度来讲,
这个比懒汉式单例类稍差些。
从速度和反应时间角度来讲,则比懒汉式单例类稍好些。然而,懒汉式单例类在实例化时,必须处
理好在多个线程同时首次引用此类时的访问限制问题,特别是当单例类作为资源控制器,在实例化时必
然涉及资源初始化,而资源初始化很有可能耗费时间。这意味着出现多线程同时首次引用此类的机率变
得较大。
饿汉式单例类可以在Java 语言内实现, 但不易在C++ 内实现,因为静态初始化在C++ 里没有固定
的顺序,因而静态的m_instance 变量的初始化与类的加载顺序没有保证,可能会出问题。这就是为什么
GoF 在提出单例类的概念时,举的例子是懒汉式的。他们的书影响之大,以致Java 语言中单例类的例子
也大多是懒汉式的。实际上,本书认为饿汉式单例类更符合Java 语言本身的特点。
3 登记式单例类.(GOF)为了克服饿汉式单例类及懒汉式单例类均不能继承的缺点而设计的.
只是它的子类实例化的方式只能是懒汉式的, 这是无法改变的。类似Spring里面的方法,将
类名注册,下次从里面直接获取。 查看复制到剪切板打印
import java.util.HashMap;
public class RegSingleton
{
static private HashMap m_registry = new HashMap();
static
{
RegSingleton x = new RegSingleton();
m_registry.put(x.getClass().getName(), x);
}
/**
* 保护的默认构造子
*/
protected RegSingleton()
{
}
/**
* 静态工厂方法,返还此类惟一的实例
*/
static public RegSingleton getInstance(String name)
{
if (name == null)
{
name = "com.javapatterns.singleton.demos.RegSingleton";
}
if (m_registry.get(name) == null)
{
try
{
m_registry.put(name, Class.forName(name).newInstance());
}
catch (Exception e)
{
System.out.println("Error happened.");
}
}
return (RegSingleton) (m_registry.get(name));
}
** * 一个示意性的商业方法 */
public String about() {
return "Hello, I am RegSingleton.";
}
}
它的子类RegSingletonChild 需要父类的帮助才能实例化。
java 代码
public class RegSingletonChild extends RegSingleton
{
public RegSingletonChild()
{
}
/**
* 静态工厂方法
*/
static public RegSingletonChild getInstance()
{
return (RegSingletonChild) RegSingleton.getInstance("com.javapatterns.singleton.demos.RegSingletonChild");
}
/** * 一个示意性的商业方法 */
public String about() {
return "Hello, I am RegSingletonChild.";
}
}
在GoF 原始的例子中,并没有getInstance() 方法,这样得到子类必须调用的
getInstance(String name)方法并传入子类的名字,因此很不方便。
此处在登记式单例类子类的例子里,加入了getInstance() 方法,这样做的好处是
RegSingletonChild 可以通过这个方法,返还自已的实例。而这样做的缺点是,
由于数据类型不同,无法在RegSingleton 提供这样一个方法。
由于子类必须允许父类以构造子调用产生实例,因此,它的构造方法必须是公开的。
这样一来,就等于允许了以这样方式产生实例而不在父类的登 记中。这是登记式单例类的一个缺点。
GoF 曾指出,由于父类的实例必须存在才可能有子类的实例,这在有些情况下是一个浪费。
这是登记式单例类的另一个缺点。
4、使用单例模式有一个必要条件:在一个系统要求一个类只有一个实例时才应当使用单例模式。
几种“单例”模式之间的区别 “单例”的概念是说,数据,在指定的范围内,只有一份。
这个所谓的“指定的范围”可能是每进程、每AppDomain、每线程,也可能是每调用。
为了在指定的范围内“单例”,可能要采用不同的技术。比方说一个普通的静态属性Instance可以提供很
happy的每AppDomain范围;一个ThreadStaticAttribute修饰的static域可以提供每线程范围;一个
CallContextStaticAttribute(这东东得自定义,回头帖个实现)来提供每调用范围等等。 今天主要讨论不是这些范围如何如何,是单例的实现方式之间的不同。下面,我们假设一个进程中唯一的一个
AppDomain中实现单例。 从实现上来说,“单例”一般有三种方式: 1、static class。该类中的方法、属性、变量统统都只有一份。 2、一个静态的Insatnce属性或getInstance()方法,也就是标准的Singleton模式。 3、Monostate模式。 对1,那没啥可说的,没有继承,也就没有多态,比较死板,在类第一次被使用时初始化。
对2,可以继承,有多态,问题在于所有的派生类都得自己实现Instance属性或者getInstance方法
才能使派生类也是Singleton。在第一次使用Instance属性或调用getInstance方法时初始化。
对3,可以继承,可以多态。内部依靠多个实例对象共享相同的静态变量(跟享元模式类似。flyweight,
每次看到这个中文翻译都敬仰的一塌糊涂)达到数据只有一份的目的。派生类天生就是Singleton的。 依据需求,简单应用就直接1;对2,还没碰到过不能用1代替的情况,基本上也没啥变态需求要重载
Singleton的某些功能;对3,唯一用过的地方是数据一部分是每AppDomain范围,一部分是每调用“单例”,
对不同的调用,每调用“单例”中的数据不同。
文章出处:DIY部落(http://www.diybl.com/course/3_program/java/javaxl/20090302/156317.html)