设计模式之单例模式

最新推荐文章于 2022-01-13 17:26:53 发布

can_chen

最新推荐文章于 2022-01-13 17:26:53 发布

阅读量609

点赞数 6

分类专栏：设计模式文章标签：设计模式单例模式 Singleton java

本文链接：https://blog.csdn.net/can_chen/article/details/105049999

版权

设计模式专栏收录该内容

11 篇文章 1 订阅

订阅专栏

什么是单例模式？

所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例，并且对该类只提供一个取得其对象实例的方法(公有的静态方法)

优点：由于单例模式只生成一个实例，减少了系统性能的开销

单例模式的常见场景

windows的任务管理器是使用单例模式，比如我打开了一个任务管理器，再想打开任务管理器，它不会再弹出一个来，而保证桌面只出现一个任务管理器
在Spring中，每个bean默认就是单例的（可以通过设置bean的作用域来使它变成多例的）
在Servlet编程中，每个Servlet就是单例的
数据库连接池的设计一般也是单例的

单例模式的八种方式

（其实是五种，这里写成八种只是为了细分出来）

饿汉式（静态变量）

class Singleton1{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton1(){
	}
	//本类内部创建对象实例
	private static Singleton1 instance=new Singleton1();
	//公有的静态方法，返回实例对象
	public static Singleton1 getInstance(){
		return instance;
	}
}

优缺点：

1)优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。

2)缺点：在类装载的时候就完成实例化，没有达到 Lazy Loading 的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费

3)这种方式基于 classloder 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，在单例模式中大多数都是调用 getInstance 方法，但是导致类装载的原因有很多种，因此不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 就没有达到 lazy loading 的效果

4)结论：这种单例模式不建议用，可能造成内存浪费

饿汉式（静态代码块）

class Singleton2{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton2(){
	}
	//本类内部创建对象实例
	private static Singleton2 instance;
	static{
		instance=new Singleton2();
	}
	//公有的静态方法，返回实例对象
	public static Singleton2 getInstance(){
		return instance;
	}
}

优缺点：

这种方式和饿汉式（静态变量）其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和饿汉式（静态变量）是一样的。

懒汉式（线程不安全）

class Singleton3{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton3(){
	}
	private static Singleton3 instance;
	//提供一个静态的公有方法，当使用到该方法时，才去创建 instance
	public static Singleton3 getInstance(){
		if(instance==null){
			instance=new Singleton3();
		}
		return instance;
	}
}

优缺点：

1)起到了 Lazy Loading 的效果，但是只能在单线程下使用。

2)如果在多线程下，一个线程进入了 if (instance == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。

3)结论：在实际开发中，不要使用这种方式。

懒汉式（线程安全，同步方法，效率低）

class Singleton4{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton4(){
	}
	private static Singleton4 instance;
	//提供一个同步静态的公有方法，当使用到该方法时，才去创建 instance
	public static synchronized Singleton4 getInstance(){
		if(instance==null){
			instance=new Singleton4();
		}
		return instance;
	}
}

优缺点：

1)解决了线程安全问题

2)效率太低了，每个线程在想获得类的实例时候，执行 getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接 return 就行了。方法进行同步效率太低。

3)结论：在实际开发中，不推荐使用这种方式

懒汉式（线程不安全，同步代码块，效率高）

class Singleton5{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton5(){
	}
	private static Singleton5 instance;
	//提供一个静态的公有方法，当使用到该方法时，才去创建 instance
	public static Singleton5 getInstance(){
		if(instance==null){
			synchronized (Singleton5.class) {
				instance=new Singleton5();
			}		
		}
		return instance;
	}
}

优缺点：

1)使用同步代码块解决了效率问题。

2)是线程不安全的，如果在多线程下，一个线程进入了 if (instance == null)判断语句块，进而进入同步代码块，还未执行完毕，另一线程也进入if块，在同步代码块外面等待前一个线程执行完再进入，同样会产生多个实例。所以在多线程环境下不可使用这种方式。

3)结论：在实际开发中，不要使用这种方式。

双重检查（Double-Check）/双重锁懒汉模式（Double-Check-Lock）/DCL

class Singleton6{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton6(){
	}
	//private static Singleton6 instance;
	private volatile static Singleton6 instance;
	//提供一个静态的公有方法，当使用到该方法时，才去创建 instance
	public static Singleton6 getInstance(){
		if(instance==null){
			synchronized (Singleton6.class) {
				if(instance==null){
					instance=new Singleton6();
				}	
			}		
		}
		return instance;
	}
}

优缺点：
1)Double-Check 概念是多线程开发中常使用到的，如代码中所示，我们进行了两次 if (instance == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断 if (instance == null)，直接 return 实例化对象，也避免的反复进行方法同步。

2)线程安全；延迟加载；效率较高

3)注意：由于jvm存在乱序执行功能，DCL也会出现线程不安全的情况。具体分析如下：instance = new Singleton6();这个步骤，其实在jvm里面的执行分为三步：1.在堆内存开辟内存空间。2.在堆内存中实例化Singleton6里面的各个参数（执行构造方法）。3.把对象指向堆内存空间。由于jvm存在乱序执行功能，所以可能在2还没执行时就先执行了3，如果此时再被切换到线程B上，由于执行了3，instance已经非空了，会被直接拿出来用，这样的话，就会出现异常。这个就是著名的DCL失效问题。不过在JDK1.5之后，官方也发现了这个问题，故而具体化了volatile，即在JDK1.6及以后，只要定义为private volatile static Singleton6 instance = null;就可解决DCL失效问题。volatile确保instance每次均自己在主内存中读取，这样虽然会牺牲一点效率，但也无伤大雅。

4)对于jvm乱序使得双重检查方式也可能出现错误，我的理解是：假设第一个线程已经执行到instance = new Singleton6();这行代码了，但是它在完成这行代码的三个操作时发生了乱序，即分配完内存后就直接把引用指向该对象，还没有执行构造方法；此时另一个线程来到了最外面的“if(instance==null)”这行代码，发现instance不为null，就直接return instance了，那么使用这个instance就会出现错误。

静态内部类（饿汉式的改进）

class Singleton7{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton7(){
	}
	//创建一个静态内部类，在静态内部类里面实例化对象
	private static class SingletonInsatnce{
		private static final Singleton7 instance=new Singleton7();
	}
	public static Singleton7 getInstance(){
		return SingletonInsatnce.instance;
	}
}

优缺点：

1)这种方式采用了类装载的机制来保证初始化实例时只有一个线程。

2)加载一个类时，不管其内部类是静态的还是非静态，内部类不会同时被加载。一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。因此静态内部类方式在 Singleton7 类被装载时并不会立即实例化，而是在需要实例化时，调用 getInstance 方法，才会装载 SingletonInstance 类，从而完成 Singleton7 的实例化。

3)类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM 帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。

4)优点：避免了线程不安全，利用静态内部类特点实现延迟加载，效率高

5)结论：推荐使用

反射可以破坏以上几种方式的单例模式

class Singleton6{
	//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton6(){
	}
	//private static Singleton6 instance;
	private volatile static Singleton6 instance;
	//提供一个静态的公有方法，当使用到该方法时，才去创建 instance
	public static Singleton6 getInstance(){
		if(instance==null){
			synchronized (Singleton6.class) {
				if(instance==null){
					instance=new Singleton6();
				}	
			}		
		}
		return instance;
	}
}

public static void main(String[] args) throws Exception{
		Singleton6 instance1=Singleton6.getInstance();
		Singleton6 instance2=Singleton6.getInstance();
		System.out.println(instance1==instance2);
		System.out.println(instance1.hashCode());
		System.out.println(instance2.hashCode());
		
		System.out.println("-----------------------------");
		Class c=Singleton6.class;
		Constructor<Singleton6> constructor = c.getDeclaredConstructor();
		constructor.setAccessible(true);//暴力反射
		Singleton6 instance3 = constructor.newInstance();
		
		System.out.println(instance1==instance3);
		System.out.println(instance3.hashCode());
	}

true
27134973
27134973
-----------------------------
false
1284693

可以看到，使用反射可以获取到类的私有构造方法，然后通过构造方法可以创建一个实例对象，每次通过反射创建的对象都是不同的，那么单例模式就不复存在了，下面我们对类的私有构造方法进行一些改进：

//构造方法私有化，使外部不能通过new创建一个对象
	private Singleton6(){
		synchronized(Singleton6.class){
			if(instance!=null){
				throw new RuntimeException("休想通过反射来破坏单例!");
			}
		}
	}

以上改进后，通过类的反射机制创建对象，执行构造方法的时候会判断该类是否已存在一个对象实例了，如果已经存在了，那么会抛出异常，也是无法再创建了，可以说，一定程度上也保证了单例模式。

上面那种情况是反射创建对象之前已经存在一个实例对象了，那么想通过反射创建对象，由于instance不为null了，所以无法创建；

下面再进行修改，假如我们反射创建对象之前没有存在一个实例对象，那么instance始终为null,无论通过多少次反射创建对象都是可以的，单例模式依旧不复存在，如下：

public static void main(String[] args) throws Exception{
		
		Class c=Singleton6.class;
		Constructor<Singleton6> constructor = c.getDeclaredConstructor();
		constructor.setAccessible(true);//暴力反射
		Singleton6 instance3 = constructor.newInstance();
		Singleton6 instance4 = constructor.newInstance();
		
		System.out.println(instance3==instance4);
		System.out.println(instance3.hashCode());
		System.out.println(instance4.hashCode());
	}

false
27134973
1284693

使用一个标志位来解决上面代码存在的问题

private static boolean flag=false;
	private Singleton6(){
		synchronized (Singleton6.class) {
			if(flag==false){
				flag=true;
			}else{
				throw new RuntimeException("不要试图用反射来破坏我们的单例");
			}
		}
	}

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at singleton.type6.main(type6.java:13)
Caused by: java.lang.RuntimeException: 休想通过反射来破坏单例!
	at singleton.Singleton6.<init>(type6.java:35)
	... 5 more

虽然上面的方式一定程度上可以避免反射破坏单例，但是要知道反射可不是一般的霸道，它依旧可以将私有的标志位设置成false！

枚举

public class type8 {

	public static void main(String[] args) {
		Singleton8 instance1=Singleton8.INSTANCE;
		Singleton8 instance2=Singleton8.INSTANCE;
		System.out.println(instance1==instance2);
		System.out.println(instance1.hashCode());
		System.out.println(instance2.hashCode());
	}
}

/**
 *  枚举
 * @author cj_chen
 *
 */
enum Singleton8{
	INSTANCE;
	public Singleton8 getInstance(){
		return Singleton8.INSTANCE;
	}
}

这借助 JDK1.5 中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。结论：最推荐使用的方式，因为前面几种方式都可以通过反射来破坏，但是由构造方法的newInstance方法源码可以看到，该方法作用在枚举就失效了，直接抛出异常，也就是说反射无法破坏枚举。

以下是构造方法的newInstance方法源码

@CallerSensitive
    public T newInstance(Object ... initargs)
        throws InstantiationException, IllegalAccessException,
               IllegalArgumentException, InvocationTargetException
    {
        if (!override) {
            if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
                Class<?> caller = Reflection.getCallerClass();
                checkAccess(caller, clazz, null, modifiers);
            }
        }
        if ((clazz.getModifiers() & Modifier.ENUM) != 0)
            throw new IllegalArgumentException("Cannot reflectively create enum objects");
        ConstructorAccessor ca = constructorAccessor;   // read volatile
        if (ca == null) {
            ca = acquireConstructorAccessor();
        }
        @SuppressWarnings("unchecked")
        T inst = (T) ca.newInstance(initargs);
        return inst;
    }