单例模式
单例模式:单例模式的核心是保证一个类只有一个实例,并且提供一个访问实例的全局访问点。
单例模式使用场景
1.spring中bean对象的模式实现方式
2.servlet中每个servlet的实例
3.springmvc和strust1框架中,控制器对象是单例模式
4.应用程序的日志应用,一般都用单例模式实现,这一般是由于共享的日志文件一直处于打开状态,因为只能有一个实例去操作,否则内容不好追加。
5.操作系统的文件系统,也是大的单例模式实现的具体例子,一个操作系统只能有一个文件系统。
6.项目中,读取配置文件的类,一般也只有一个对象。没有必要每次使用配置文件数据,每次new一个对象去获取。
7.数据库连接池的设计一般也是采用单例模式,因为数据库连接是一种数据库资源。
单例模式的优点
1.由于单例模式只生成一个实例,减少了系统性能开销,当一个对象的产生需要比较多的资源时,如读取配置,产生其他依赖对象时,则可以通过在应用启动时直接产生一个单例对象,然后永久驻留内存的方式来解决。
2.单例模式可以在系统设置全局的访问点,优化环共享资源访问,例如可以设计一个单例类,负责所有数据表的映射处理。
单例模式的实现方式
饿汉式
也就是类加载的时候立即实例化对象,实现的步骤是先私有化构造方法,对外提供唯一的静态入口方法,实现如下:
饿汉式单例模式代码中,static变量会在类装载时初始化,此时也不会涉及对个线程对象访问该对象的问题,虚拟机保证只会装载一次该类,肯定不会发生并发访问的问题。因此可以省略synchronized关键字。
问题:如果只是加载本类,而不是要调用getInstance(),甚至永远没有调用,则会造成资源浪费。
懒汉式
此种方式在类加载后如果我们一直没有调用getInstance方法,那么就不会实例化对象。实现了延迟加载,但是因为在方法添加了synchronized关键字,每次调用getInstance方法都会同步,所以对性能的影响比较大。
双重检测锁式
这个模式将同步内容下方到if内部,提高了执行的效率不必每次获取对象时都进行同步,只有第一部才同步创建了以后就没必要了。
问题:由于编译器优化原因和JVM底层内部模型原因,偶尔会出现问题。不建议使用。
静态内部类
注意点:
1.外部类没有static属性,则不会像饿汉式那样立即加载对象。
2.只有真正调用getInstance()才会加载静态内部类。加载类时是线程安全的instance是static final类型,保证了内存中只有这样一个实例存在,而且只能被赋值一次,从而保证了线程安全性。
3.兼备了并发高效调用和延迟加载的优势! 兼备了并发高效调用和延迟加载的优势。
枚举单例
测试代码
优点:
1.实现简单
2.枚举本身就是单例模式。由JVM根本上提供保障,避免通过反射和反序列化的漏洞
缺点:
无延迟加载
单例模式的漏洞
1.通过反射的方式我们依然可用获取多个实例(除了枚举的方式)。
输出结果:
产生了两个对象,违背了单例设计模式的初衷。
解决方式是在无参构造方法中手动抛出异常控制
2.通过反序列化的方式也可以破解上面几种方式(除了枚举的方式)。
输出结果
是两个不同的对象,同样破坏了单例模式,这种情况我们只需要在单例类中重写readResolve方法并在该方法中返回单例对象即可
说明:readResolve方法是基于回调的,反序列化时,如果定义了readResolve()则直接返回此方法指定的对象,而不需要在创建新的对象。
总结
- 单例对象占用资源少,不需要延时加载:
枚举式 好于 饿汉式
- 单例对象占用资源大,需要延时加载:
静态内部类式 好于 懒汉式