设计模式学习之——单例模式
2014-04-12 21:45
246 查看
定义:单例模式(Singleton Pattern):Ensure a class has only one instance, and provide a global point of access to it.
(确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例)
一、例子
如 一个朝代只能有一个皇帝:所以我们要求一个类只能生成一个对象(皇帝),那么如何只让一个类只产生一个对象呢?
我们知道使用new关键字创建对象时,会根据输入的参数调用相应的构造函数,如果我们将构造函数设置为private私有访问权限不就可以禁止外部创建对象了吗?
我们这样设计两个类:Emperor代表皇帝类,Minister代表臣子类,代码如下:
通过定义一个私有访问权限的构造函数,避免其他类new出来一个对象,而Emperor自己则可以new一个对象出来,其他类对该类的访问都可以通过getInstance获得同一个对象。
臣子类如下:
这就是单例模式
通用类图
Singleton类称为单例类,通过使用private的构造函数确保了在一个应用中只产生一个实例,并且是自行实例化的(在Singleton中自己使用new Singleton())。
二、单例模式通用代码:
三、单例模式优点:
● 由于单例模式在内存中只有一个实例,减少了内存开支
● 由于单例模式只生成一个实例,所以减少了系统的性能开销
如:当一个对象的产生需要比较多个的资源时,如读取配置、产生其他依赖对象时,则可以通过在应用中启动时直接产生一个到单例对象,然后用永久驻留内存的方式来解决
● 单例模式可以避免对资源的多重占用
● 单例模式可以在系统设置全局的访问点,优化和共享资源访问,例如可以设计一个单例类,负责所有数据表的映射处理
四、单例模式缺点:
● 单例模式一般没有借口,扩展很困难
因为借口对单例模式是没有任何意义的,它要求“自行实例化”,并且提供单一实例,而借口或抽象类是不可能被实例化的(特殊情况除外)
● 单例模式对测试是不利的
● 单例模式与单一职责原则有冲突
一个类应该只实现一个逻辑,而不关心它是否是单例的,是不是要单例取决于环境,单例模式把“要单例”和业务逻辑融合在一个类中
五、单例模式使用场景:
● 要求生成唯一序列号的环境
● 在整个项目中需要一个共享访问点或共享数据
如:一个Web页面上的计数器,可以不用每次刷新都记录到数据库中,使用单例模式保持计数器的值,并确保是线程安全的
● 创建一个对象需要消耗的资源过多
如:要访问IO和数据库等资源
● 需要定义大量的静态常量和静态方法的场景(当然,可以直接声明为static的方式)
如:工具类
六、单例模式的注意事项:
高并发情况下,注意单例模式的线程同步问题。
如一个线程A执行到 singleton = new Singleton() ,但是还没有获得对象,第二个线程B也在执行,并且执行到了if(singleton == null) 的判断,那么此时B获得的判断条件也是真,于是继续运行下去,线程A获得了一个对象,线程B也获得了一个对象,内存中存在了两个对象!!
解决:解决线程不安全的方法很多,可以在getSingleton方法前加synchronized关键字,也可以在getSingleton方法内增加synchronized来实现,但都不是最优秀的单例模式。
建议使用上文中出现的:单例模式通用代码 这个方式,该方式成为饿汉式单例
其次,需要考虑对象复制情况。在Java中对象默认不可复制,若实现了Cloneable接口,并实现了clone方法,则可以直接通过对象复制方法创建一个新对象,对象复制是不用调用类的构造函数的,所以即使是私有的构造函数,对象仍然可以被复制。
解决该问题的最好方法就是单例类不要事先Cloneable接口!
欢迎转载,转载注明出处,谢谢
Mr.傅:阅读自《设计模式之禅》
(确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例)
一、例子
如 一个朝代只能有一个皇帝:所以我们要求一个类只能生成一个对象(皇帝),那么如何只让一个类只产生一个对象呢?
我们知道使用new关键字创建对象时,会根据输入的参数调用相应的构造函数,如果我们将构造函数设置为private私有访问权限不就可以禁止外部创建对象了吗?
我们这样设计两个类:Emperor代表皇帝类,Minister代表臣子类,代码如下:
public class Emperor { private static final Emperor emperor = new Emperor(); //初始化一个皇帝 private Emperor(){} public static Emperor getInstance(){ return emperor; } //皇帝发话 public static void say(){ System.out.printIn("我是秦始皇....."); } }
通过定义一个私有访问权限的构造函数,避免其他类new出来一个对象,而Emperor自己则可以new一个对象出来,其他类对该类的访问都可以通过getInstance获得同一个对象。
臣子类如下:
public class Minister { public static void mian(String[] args){ for(int day=0; day<3; day++){ Emperor emperor = Emperor.getInstance(); emperor.say(); } } }输出结果:
我是秦始皇..... 我是秦始皇..... 我是秦始皇.....
这就是单例模式
通用类图
Singleton类称为单例类,通过使用private的构造函数确保了在一个应用中只产生一个实例,并且是自行实例化的(在Singleton中自己使用new Singleton())。
二、单例模式通用代码:
public class Singleton { private static final Singleton singleton = new Singleton(); //限制产生多个对象 private Singleton(){} //通过该方法获得实例对象 public static Singleton getSingleton(){ return singleton; } //类中的其他方法,尽量static public static void doSomething(){} }
三、单例模式优点:
● 由于单例模式在内存中只有一个实例,减少了内存开支
● 由于单例模式只生成一个实例,所以减少了系统的性能开销
如:当一个对象的产生需要比较多个的资源时,如读取配置、产生其他依赖对象时,则可以通过在应用中启动时直接产生一个到单例对象,然后用永久驻留内存的方式来解决
● 单例模式可以避免对资源的多重占用
● 单例模式可以在系统设置全局的访问点,优化和共享资源访问,例如可以设计一个单例类,负责所有数据表的映射处理
四、单例模式缺点:
● 单例模式一般没有借口,扩展很困难
因为借口对单例模式是没有任何意义的,它要求“自行实例化”,并且提供单一实例,而借口或抽象类是不可能被实例化的(特殊情况除外)
● 单例模式对测试是不利的
● 单例模式与单一职责原则有冲突
一个类应该只实现一个逻辑,而不关心它是否是单例的,是不是要单例取决于环境,单例模式把“要单例”和业务逻辑融合在一个类中
五、单例模式使用场景:
● 要求生成唯一序列号的环境
● 在整个项目中需要一个共享访问点或共享数据
如:一个Web页面上的计数器,可以不用每次刷新都记录到数据库中,使用单例模式保持计数器的值,并确保是线程安全的
● 创建一个对象需要消耗的资源过多
如:要访问IO和数据库等资源
● 需要定义大量的静态常量和静态方法的场景(当然,可以直接声明为static的方式)
如:工具类
六、单例模式的注意事项:
高并发情况下,注意单例模式的线程同步问题。
public class Singleton { private static Singleton singleton = null; private Singleton(){} public static Singleton getSingleton(){ if(singleton == null){ singleton = new Singleton(); } return singleton; } }上述代码中低并发情况下不会出现问题,如果系统压力增大,并发量增加时则可能在内存中存在多个实例了,为何呢?
如一个线程A执行到 singleton = new Singleton() ,但是还没有获得对象,第二个线程B也在执行,并且执行到了if(singleton == null) 的判断,那么此时B获得的判断条件也是真,于是继续运行下去,线程A获得了一个对象,线程B也获得了一个对象,内存中存在了两个对象!!
解决:解决线程不安全的方法很多,可以在getSingleton方法前加synchronized关键字,也可以在getSingleton方法内增加synchronized来实现,但都不是最优秀的单例模式。
建议使用上文中出现的:单例模式通用代码 这个方式,该方式成为饿汉式单例
其次,需要考虑对象复制情况。在Java中对象默认不可复制,若实现了Cloneable接口,并实现了clone方法,则可以直接通过对象复制方法创建一个新对象,对象复制是不用调用类的构造函数的,所以即使是私有的构造函数,对象仍然可以被复制。
解决该问题的最好方法就是单例类不要事先Cloneable接口!
欢迎转载,转载注明出处,谢谢
Mr.傅:阅读自《设计模式之禅》
相关文章推荐
- 设计模式学习笔记--适配器(Adapter)模式
- 设计模式学习
- php设计模式学习记录(上)
- Java-马士兵设计模式学习笔记-策略模式-模拟Comparable接口
- 【软考学习】设计模式——建造者模式
- Java-马士兵设计模式学习笔记-策略模式-模拟 Comparator接口
- 23种设计模式介绍以及单例模式的学习
- head first 设计模式学习随笔(4)----抽象工厂模式
- 学习JavaScript设计模式(代理模式)
- (设计模式学习)设计模式学习之基础原则
- java/android 设计模式学习笔记(3)---工厂方法模式
- 学习:java设计模式—Adapter模式
- java 设计模式学习笔记十一flyweight享元设计模式
- 设计模式学习--Prototype
- java/android 设计模式学习笔记(20)---迭代器模式
- 设计模式之Bridge学习笔记
- 浅谈设计模式的学习(下)
- 设计模式学习—单列模式
- 学习设计模式--观察者模式(C++)
- 设计模式学习(十五) 策略模式