一、问题引出
单例模式是设计模式中使用比较普遍的模式之一,它是一种对象创建模式,用于产生一个对象的实例,并能确保系统中一个类只产生一个实例,这样可以带来两大好处:
(1)对于频繁使用的对象实例,可以省略创建对象实例所花费的时间,这对于那些重量级的对象而言,是一笔非常可观的系统开销。
(2)由于new操作的次数减少,可以减轻GC压力,缩短GC停顿时间。
综上可知,对于系统关键组件和被频繁使用的对象实例,使用单例模式可以有效的改善系统的性能。
下面分析单例模式的几种实现方式:
二、单例模式实现与分析
1. 最简单的实现
先看代码如下:
package com.jason.design.singleton;
/**
* 简单的单例模式实现,但是不是懒加载形式
*/
public class SingletonClass1 {
private static final SingletonClass1 instance = new SingletonClass1();
private SingletonClass1(){}
public static SingletonClass1 getInstance(){
return instance;
}
}
首先,类的构造函数写成private的,从而保证别的类不能实例化此类。其次,在类中提供一个静态的实例instance并提供静态的getInstance方法给使用者。这样,使用者就可以通过这个引用使用到这个类的实例了。
2. 性能优化——延迟加载(懒加载lazy loaded)
上述单例的实现方式很简单,并且非常可靠。但是有一个问题:无论这个类是否被使用,都会创建一个instance对象。如果这个创建过程很耗时,并且这个类还并不一定会被使用,那么这个创建过程就是无用的。我们做延迟加载优化:
package com.jason.design.singleton;
/**
* 延迟加载但是非线程安全的单例模式
*/
public class SingletonClass2 {
private static SingletonClass2 instance = null;
private SingletonClass2(){}
public static SingletonClass2 getInstance(){
if (instance == null){
instance = new SingletonClass2();
}
return instance;
}
}
首先,把instance初始化为null,确保系统启动时没有额外的负载,因为创建过程不在声明处,所以那个final的修饰必须去掉。
其次,在getInstance()方法中,判断当前单例是否已经存在,若存在则返回,不存在再建立单例。
3. 线程安全问题
上述代码在单线程情况下,没有什么问题,可是如果是多线程,会有线程安全问题,在并发情况下,线程可能各自拥有一个SingletonClass2的对象。
继续对其进行优化,首先想到的是加锁,在getInstance()加上同步锁,一个线程必须等待另外一个线程创建完成后才能使用这个方法,这就保证了单例的唯一性。
package com.jason.design.singleton;
/**
* 同步获取单例方法的单例模式,这样会导致每次获取单例时都是同步方法,粒度过大
*/
public class SingletonClass3 {
private static SingletonClass3 instance = null;
private SingletonClass3(){}
public static synchronized SingletonClass3 getInstance(){
if (instance == null){
instance = new SingletonClass3();
}
return instance;
}
}
4. 性能优化
上述代码引入了synchronized锁,而且是加在整个方法上的,这样性能可能受到影响。分析一下不难发现出现3中线程安全问题原因是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行就能保证线程安全。所以,可以将同步块进行缩小粒度,首先去掉getInstance()的同步操作,然后把同步锁加载if语句上,修改如下:
package com.jason.design.singleton;
public class SingletonClass4 {
private static SingletonClass4 instance = null;
private SingletonClass4() {
}
public static SingletonClass4 getInstance() {
synchronized (SingletonClass4.class) {
if (instance == null) {
instance = new SingletonClass4();
}
}
return instance;
}
}
继续分析发现,即使缩小了同步块的粒度,每次调用getInstance()的时候还是需要每次都调用同步块中的内容,性能问题还是存在。此时可用到Double-check的模式,继续修改如下:
package com.jason.design.singleton;
/**
* Double-Check模式的单例模式实现
*/
public class SingletonClass5 {
private static SingletonClass5 instance = null;
private SingletonClass5(){}
private static SingletonClass5 getInstance(){
if (instance == null) {
synchronized (SingletonClass5.class) {
if (instance == null) {
instance = new SingletonClass5();
}
}
}
return instance;
}
}
首先判断instance是不是为null,如果为null,加锁初始化;如果不为null,直接返回instance。但是这样就够了吗?刚好最近在阅读Dubbo源码的时候看到了这种double-check的应用:在Dubbo源码com/jason/properties/ConfigUtils.java类的时候有这样一段代码:
private static volatile Properties PROPERTIES;
public static Properties getProperties() {
if (PROPERTIES == null) {
synchronized (ConfigUtils.class) {
if (PROPERTIES == null) {
String path = System.getProperty(Constants.DUBBO_PROPERTIES_KEY);
if (path == null || path.length() == 0) {
path = System.getenv(Constants.DUBBO_PROPERTIES_KEY);
if (path == null || path.length() == 0) {
path = Constants.DEFAULT_DUBBO_PROPERTIES;
}
}
PROPERTIES = ConfigUtils.loadProperties(path, false, true);
}
}
}
return PROPERTIES;
}
对比代码可以发现,dubbo中的实现对于PROPERTIES的修饰符多了一个volatile,这个区别在哪里?
下面来想一下,创建一个变量需要哪些步骤呢?一个是申请一块内存,调用构造方法进行初始化操作,另一个是分配一个指针指向这块内存。这两个操作谁在前谁在后呢?JVM规范并没有规定。那么就存在这么一种情况,JVM是先开辟出一块内存,然后把指针指向这块内存,最后调用构造方法进行初始化。
下面我们来考虑这么一种情况:线程A开始创建SingletonClass的实例,此时线程B调用了getInstance()方法,首先判断instance是否为null。按照我们上面所说的内存模型,A已经把instance指向了那块内存,只是还没有调用构造方法,因此B检测到instance不为null,于是直接把instance返回了——问题出现了,尽管instance不为null,但它并没有构造完成,就像一套房子已经给了你钥匙,但你并不能住进去,因为里面还没有收拾。此时,如果B在A将instance构造完成之前就是用了这个实例,程序就会出现错误了!
5、最终实现
(1)同步+Double-check方式:
在JDK 5之后,Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前,volatile是个关键字,但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整,读变量不能和之后的读写代码调整!因此,只要我们简单的把instance加上volatile关键字就可以了。
package com.jason.design.singleton;
/**
* Double-Check模式的单例模式实现,并且加入了volatile的,可保证安全
*/
public class SingletonClass6 {
private static volatile SingletonClass6 instance = null;
private SingletonClass6(){}
private static SingletonClass6 getInstance(){
if (instance == null) {
synchronized (SingletonClass6.class) {
if (instance == null) {
instance = new SingletonClass6();
}
}
}
return instance;
}
}
(2)静态内部类实现方式:
然而,这只是JDK1.5之后的Java的解决方案,那之前版本呢?其实,还有另外的一种解决方案,并不会受到Java版本的影响,即:Initialization on Demand Holder(IODH),详见 http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom
package com.jason.design.singleton;
/**
* 静态内部类实现的单例模式
*/
public class SingletonClass7 {
private SingletonClass7(){}
private static class SingletonInstance{
private static final SingletonClass7 instance = new SingletonClass7();
}
public SingletonClass7 getInstance(){
return SingletonInstance.instance;
}
}
因为SingletonClass7没有static的属性,因此在没有被调用时并不会被初始化,满足延迟加载的优点,直到调用getInstance()的时候,会首先加载SingletonClassInstance类,这个类有一个static的SingletonClass实例,因此需要调用SingletonClass的构造方法,然后getInstance()将把这个内部类的instance返回给使用者。由于这个instance是static的,因此并不会构造多次。
由于SingletonClassInstance是私有静态内部类,所以不会被其他类知道,同样,static语义也要求不会有多个实例存在。并且,JSL规范定义,类的构造必须是原子性的,非并发的,因此不需要加同步块。同样,由于这个构造是并发的,所以getInstance()也并不需要加同步。
综上:使用内部类的方式实现单例,即可以做到延迟加载,也不必使用同步,是一种比较好的实现方式。
(3)单元素枚举实现
代码如下:
package com.jason.design.singleton;
/**
* 枚举的方式实现单例模式
*/
public enum EnumSingleton {
INSTANCE;
private SingletonClass8 instance = null;
private EnumSingleton() {
instance = new SingletonClass8();
}
public SingletonClass8 getInstance(){
return instance;
}
}
单例使用方式:
EnumSingleton.INSTANCE.getInstance();
下面我们来看看单例是如何被保证的:
首先,在枚举中我们明确了构造方法限制为私有,在我们访问枚举实例时会执行构造方法,同时每个枚举实例都是static final类型的,也就表明只能被实例化一次。在调用构造方法时,我们的单例被实例化。
也就是说,因为enum中的实例被保证只会被实例化一次,所以我们的INSTANCE也被保证实例化一次。
可以看到,枚举实现单例还是比较简单的,除此之外我们再来看一下Enum这个类的声明:
public abstract class Enum<E extends Enum<E>>
implements Comparable<E>, Serializable
/**
* prevent default deserialization
*/
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
throw new InvalidObjectException("can't deserialize enum");
}
/**
* Throws CloneNotSupportedException. This guarantees that enums
* are never cloned, which is necessary to preserve their "singleton"
* status.
*
* @return (never returns)
*/
protected final Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
综上,单元素枚举实现单例模式有如下优点:(1)、自由序列化 (2)、保证只有一个实例(即使使用反射机制也无法多次实例化一个枚举量)(3)、JVM保证的线程安全
6、破坏代理模式
对象的创建方式有如下四中方式:(1)new (2)克隆(3)序列化(4)反射 在上面实现的方式中,由于构造函数是private的,因此第一种方式无法破坏目前我们实现的单例模式。那么是否还有可以通过其他的三种方式创建对象呢,但其他三种方式会不会破坏单例模式:
1、克隆可能对单例模式的破坏
由克隆我们可以想到原型模式,原型模式就是通过clone方法实现对象的创建的,clone方式是Object方法,每个对象都有,那我使用一个单例模式类的对象,调用clone方法,再创建一个新的对象了,那岂不是上面说的单例模式失效了。当然答案是否定,某一个对象直接调用clone方法,会抛出异常,即并不能成功克隆一个对象。调用该方法时,必须实现一个Cloneable 接口。这也就是原型模式的实现方式。还有即如果该类实现了cloneable接口,尽管构造函数是私有的,他也可以创建一个对象。即clone方法是不会调用构造函数的,他是直接从内存中copy内存区域的。所以单例模式的类是不可以实现cloneable接口的。
2、序列化可能对单例模式的破坏
序列化一是可以实现数据的持久化;二是可以对象数据的远程传输。 如果过该类implements Serializable,那么就会在反序列化的过程中再创一个对象。这个问题的解决办法就是在反序列化时,指定反序化的对象实例,代码如下:
package com.jason.design.singleton;
import java.io.Serializable;
/**
* Double-Check模式的单例模式实现,并且加入了volatile的,可保证安全,可被串行化的单例
*/
public class SingletonClass8 implements Serializable {
private static volatile SingletonClass8 instance = null;
private SingletonClass8(){}
private static SingletonClass8 getInstance(){
if (instance == null) {
synchronized (SingletonClass8.class) {
if (instance == null) {
instance = new SingletonClass8();
}
}
}
return instance;
}
/**
* 在反序列化时,指定反序化的对象实例
* @return
*/
private Object readResolve(){
return instance;
}
}
3.反射可能对单例模式的破坏
反射是可以获取类的构造函数,再加一行 setAccessible(true);就可以调用私有的构造函数,创建对象了。那么防止反射破坏Java单例模式的方法就是:当第二次调用构造函数时抛出异常。代码如下:
package com.jason.design.singleton;
/**
* 静态内部类实现的单例模式,防止反射机制破坏单例
*/
public class SingletonClass10 {
private static volatile boolean flag = true;
private SingletonClass10(){
if (flag){
flag = false;
}else {
throw new RuntimeException();
}
}
private static class SingletonInstance{
private static final SingletonClass10 instance = new SingletonClass10();
}
public SingletonClass10 getInstance(){
return SingletonInstance.instance;
}
}
参考文献:http://www.jb51.net/article/80201.htm
http://blog.51cto.com/devbean/203501