设计模式之--单例模式(7种写法)_应用最广的设计模式-优快云博客

本文链接：https://blog.youkuaiyun.com/walkeryudev/article/details/84573247

1、单例模式介绍

单例模式是应用最广的设计模式之一，也可能是很多初级工程师唯一会使用的设计模式。在应用这个模式时，单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个全局对象，这样有利于我们协调系统整体行为。如在一个应用中，应该只有一个ImageLoader实例，这个ImageLoader中又包含有线程池，缓存系统、网络请求等，很消耗资源，因此没有理由让它构造多个实例。这种不能自由构造对象的情况，就是单例模式的使用场景。

2、单例模式的定义

确保某个类有且只有一个对象的场景，避免产生多个对象消耗过多的资源，或者某种类型的对象应该有且只有一个。例如，创建一个对象需要消耗的资源过多，如需要访问IO和数据库等资源，这时就要考虑使用单例模式

3、单例模式的实现方式

3.1懒汉模式（线程安全）

懒汉模式是声明一个静态对象，并且在用户第一次访问getInstance时进行初始化，而上述的饿汉模式是在声明静态变量的时候就已经初始化。懒汉单例模式的实现如下。

public class Singleton{
	private static Singleton instance;
	public static synchronized Singleton getInstance(){
		if(instance==null){
			instance=new Singleton();
		}
		return instance;
	}
}

你可能已经发现了，getInstance()方法中添加了synchronized关键字，也就是getInstance是一个同步方法，这就是上面所说的在多线程情况下保证单例对象唯一性的手段。细想一下，大家会发现一个问题，即使instance已经被初始化（第一次调用就会初始化instance），每次调用都会进行同步，这样会消耗不必要的资源，这也是懒汉单例模式存在的最大的问题。
小结一下:懒汉单例模式的优点是单例只有在使用的时候才会被实例化，在一定程度上节约了资源；缺点是第一次加载时需要即使进行实例化，反应稍慢，最大的问题是每次调用getInstance都进行同步，造成不必要的同步开销。这种模式不建议使用

3.2 懒汉模式（线程不安全）

public class Singleton {
    private static Singleton instance;
    private Singleton(){}
    public static Singleton getInstance(){
        if(null==instance){
            instance = new Singleton();
        }
        return instance;
    }
}

声明了一个静态对象，在用户第一次调用时初始化。这虽然节约了资源，但第一次加载时需要实例化，反应稍慢了一些，而且多线程时不能工作。

3.3 饿汉模式

public class Singleton {
    private static Singleton instance = new Singleton();
    private Singleton(){}
    public static Singleton getInstance(){        
        return instance;
    }
}

这种方式在类加载时就完成了初始化，所以类加载较慢，但是获取对象的速度快。这种方式基于类加载机制，避免了多线程的同步问题。在类加载的时候就完成了实例化，没有达到懒加载的效果。如果从始至终都没用使用过这个实例，则会造成内存的浪费。

3.4 Double Check Lock(DCL)单例实现

DCL方式实现单例模式的优点是既能够在需要时才初始化实例，又能够保证线程安全，且单例对象初始化后调用getInstance不进行同步锁，代码如下所示:

public  class Singleton{
	private static volatile Singleton sInstance = null;
	private Singleton(){
	}
	public static Singleton getInstance(){
		if(mInstance == null){
			synchronized(Singleton.class){
				if(mInstance ==null){
					sInstance= new Singleton();
				}
			}
		}
		return sInstance;
	}
	public void doSomething(){
	  System.out.println("do sth.");
	}
}

本程序的亮点自然都在getInstance方法上，可以看出getInstance方法中对instance进行了两次判空；第一层判空主要是为了避免不必要的同步，第二层的判断则是为了在null的情况下创建实例。这是什么意思呢？是不是有点摸不着头脑，下面就一起来分析一下。
假设线程A执行到sInstance = new Singleton()语句，这里看起来是一句话，但实际上它并不是一个原子操作，这代码最终会被编译成多条汇编指令，大致做了3件事：
（1）给Singleton的实例分配内存；
（2）调用Singleton()的构造函数，初始化成员字段；
（3）将sInstance对象指向分配的内存空间(此时sInstance就不是null了)
但是，由于java编译器允许处理器乱序执行，以及JDK1.5之前JMM(Java Memory Modle，即Java内存模型)中Cache、寄存器到主内存回写顺序的规定，上面的第二和第三的顺序无法保证。也就是说，执行的顺序可能是1-2-3也可能是1-3-2。如果是后者，并且在3执行完毕、2未执行之前，切换到了线程B上，这时候sInstance因为在线程A内执行过了第三点，sInstance已经是非空了，所以线程B直接取走sInstance，再使用就会出错，这就是DCL失效的问题。而且这种难以跟踪的错误很可能会隐藏很久。
在JDK1.5之后，SUN官方已经注意到这种问题，调整了JVM，具体化了volatile关键字，因此，如果JDK是1.5或者之前的版本，只需要将sInstance的定义改成private volatile static Singleton sInstance=null就可以保证sInstance对象每次都是从主内存中读取，就可以使用DCL的写法来完成单例模式。当然，volatile或多或少也会影响性能，但是考虑到程序的正确性，牺牲这点性能还是值得的。
DCL的优点：资源利用率高，第一次执行getInstance时单例对象才会被初始化，效率高。缺点：第一次加载时反应稍慢，也由于Java内存模型的原因偶尔会失败。在高并发环境下也有一定的缺陷，虽然发生的概率很小。DCL模式是使用最多的单例实现方式，它能够在需要时才实例化单例对象，并且能够在绝大多数场景下保证单例对象的唯一性，除非你的代码在并发场景比较复杂或者低于JDK6版本下使用，否则这种方法一般能够满足需求。

3.5 静态内部类单例模式

DCL虽然在一定程度上解决了资源消耗、多余的同步、线程安全等问题，但是它还是在某些情况下出现失效的问题。这个问题被称为双重检查锁定(DCL)失效，在《Java并发编程实践》一书的最后谈到了这个问题，并指出这种“优化”是丑陋的，不赞成使用的。而建议使用如下的代码替代：

public class Singleton{
	 private Singleton(){}
	 public static Singleton getInstance(){
		return SingletonHolder.sInstance;
	}
	
	/**
	* 静态内部类
	*/
	private static class SingletonHolder{
		private static final Singleton sInstance=new Singleton();
	}
}

当第一次加载Singleton类时并不会初始化sInstance，只有第一次调用Singleton的getInstance方法时才初始化sInstance。因此第一次调用会使虚拟机加载SingletonHolder类，这种方法不仅能够确保线程安全，也能够保证单例对象的唯一性，同时也延迟了单例的实例化，所以推荐使用这种方式实现单例模式。

3.6枚举单例

前面讲了一些单例模式的实现方式，但是这些实现方法不是稍显麻烦就是会在某些情况下出现问题，有没有更简单的实现方式呢？我们看看下面的实现：

public enum  Singleton {
    INSTANCE;
    public void doSomething(){
        System.out.println("do sth.");
    }
}

写法简单是枚举单例的最大优点，枚举在Java中与普通的类是一样的，不仅能够有字段，还能够有自己的方法，最重要的是默认枚举实例的创建都是线程安全的，并且在任何情况下它都是一个单例。

为什么这么说呢？在上述的几种单例模式的实现中，在一个情况下它们会出现重新创建对象的情况，那就是反序列化。
通过反序列化可以将一个单例的实例对象写到磁盘，然后再读回来，从而有效地获得一个实例。即使构造函数是私有的，反序列化时依然可以通过特殊的途径去创建类的一个新的实例，相当于调用该类的构造函数。反序列化操作提供了一个很特别的钩子函数，类中具有一个私有的、被实例化的方法readResolve(),这个方法可以让开发人员控制对象的反序列化。例如，在上述几个示例中如果要杜绝单例对象在被反序列化时重新生成对象，那么必须加入如下方法：

private Object readResolve() throws ObjectStreamException{
       return mSingleton;
   }

也就是在readResolve方法中将sInstance对象返回，而不是默认的重新生成一个新的对象。而对于枚举，并不存在这个问题，因为即使反序列化也不会重新生成新的实例。

3.7 使用容器实现单例模式

看了以上6种单例模式的实现之后，还有另一种实现:

public class   SingletonManager {
    private static Map<String, Object> objectMap = new HashMap<>(); 
    private SingletonManager(){
    }
    public static void registerService(String key,Object instance){
        if(!objectMap.containsKey(key)){
            objectMap.put(key, instance);
        }
    }
    public static Object getService(String key){
        return objectMap.get(key);
    }
}

在程序的初始，将多种单例类型注入到一个统一管理类中，在使用的时候根据key获取对象对应的对象。这种方式使得我们可以管理多种类型的单例，并且在使用时，可以通过统一的接口进行获取操作，降低了用户的使用成本，也对用户隐藏了具体实现，降低了耦合度。

不管用那种形式实现单例模式，它们的核心都是将构造函数私有化，通过静态方法获取一个唯一的实例,在获取的过程中必须保证线程安全，防止反序列化导致重新生成实例对象等问题，具体选择哪一种实现方式取决于项目本身，如，是否是复杂的并发环境、单例对象的资源消耗等。

单例模式是运用频率很高的模式，但是由于在客户端通常没有高并发的情况，因此选择哪种实现方式并不会有太大的影响。即便如此，推荐使用3.4 , 3.5使用的形式；

优点：

1.由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁得创建销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
2.由于单例模式只生成一个实例，所以减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动的时候直接产生一个单例对象，然后用永久驻留内存的方式来解决。
3.单例模式可以避免对资源的多重占用，例如一个写文件的操作，由于只用一个实例存在内存中，避免对同一个资源文件的同时操作。
4.单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如，可以设计一个单例类，负责所有数据表的映射处理。

缺点：