设计模式之单例设计模式
前面我们已经讲解了设计模式的七大设计原则,今天我们就来聊一聊设计模式中的单例设计模式,看看如何从小小单例模式衍生出来一个大世界。
适用场景:
用于需要频繁创建和销毁且消耗时间过长,耗费资源过多但是又频繁使用的对象(重量级对象),
栗子:工具类对象,Web开发中必须用到的对象(Servlet对象,假单例,构造方法不是私有的),用于操作数据库和文件的对象(数据源对象,Session工厂对象)
单例设计模式最简单的两个形态分为“懒汉式”和“饿汉式”,顾名思义,懒汉式就是基于事件驱动去加载,俗称懒加载,饿汉式就是提前加载。在程序中确定会使用到的建议饿汉式加载,不确定是否使用到使用延迟加载,这样效率会更高.
饿汉式
public class Singletion { private Singletion() { } private static Singletion singletion = new Singletion(); public static Singletion getInstance() { return singletion; } }
上面我们是通过静态变量的形式实例化一次,我们可不可以换一种下面的形式呢,我们把创建单例对象放在静态代码块中,可以实现相同的效果
public class Singletion { private Singletion() { } static{ singletion = new Singletion(); } private static Singletion singletion; public static Singletion getInstance() { return singletion; } }
看完饿汉式我们再看下懒汉式
public class Singletion { private Singletion() { } private static Singletion singletion; public static Singletion getInstance() { if(singletion==null){ return new Singletion(); } return singletion; } }
但是这种单例有一个很明显的问题,线程不安全,在多线程环境下,很有可能创建多个对象,我们需要改进一下,加锁,没错就是加锁
public class Singletion { private Singletion() { } private static Singletion singletion; public static synchronized Singletion getInstance() { if(singletion==null){ return new Singletion(); } return singletion; } }
那么我把锁加在方法上怎么样呢,如果被一个外国人看到,我想他一定会说:噢,天哪,这真是个糟糕的决定.为什么说是个糟糕的决定呢?
在我们实际开发中,一个方法中一定有许多代码要执行,我们仅仅只是想同步创建单例对象这一部分代码,而我们却把锁加在了方法上.
这就好比一个厕所有多个坑位,我们只是想在每个坑位的门上加锁,而你却把锁加在了厕所门上,当进去一个人就把厕所锁上,这样显然不太合适,因此我就再次改造了一下
public class Singletion { private Singletion() { } private static Singletion singletion; public static Singletion getInstance() { if (singletion == null) { synchronized (Singletion.class) { if (singletion == null) { return new Singletion(); } } } return singletion; } }
这样我们使用过加锁和双重检查机制解决了多线程不安全的问题,事情真的就万事大吉了?如果让一个外国人看到,我想他会说:噢,天哪,这真是个糟糕的决定.
这里我们就要聊一聊JVM.编译器和处理器的指令重排序和对象创建了
对象创建在我们new的时候到底做了些什么呢?
1:为对象分配内存空间
2:初始化对象
3:将对象指向分配的内存空间
而指令重排序做了一系列优化,对象创建的过程顺序很有可能1->3->2,那么在多线程环境下很有可能线程1执行了 1,3还没有执行2初始化对象,另一个线程调用getInstance方法发现单例对象不为null,直接返回单例对象,但是此时单例对象还没有执行2,也就是对象初始化.
为了解决指令重排序可能产生的影响,我们需要在本单例对象的静态变量上加上volitaile关键字修饰才能保证后续不会出问题.
public class Singletion { private Singletion() { } private static volatile Singletion singletion; public static Singletion getInstance() { if (singletion == null) { synchronized (Singletion.class) { if (singletion == null) { return new Singletion(); } } } return singletion; } }
那么这样就结束了?有没有办法让JVM帮助我们保证线程安全呢?毕竟我不想写太多代码,接下来我们聊一聊静态内部类
public class Singletion { private Singletion() { } private static class SingletonInside{ private static final Singletion SGT=new Singletion(); } public static Singletion getInstance() { return SingletonInside.SGT; } }
才能保证后续不会出问题.这种方式采用类加载的机制来保证线程安全,并且实现了懒加载,只有访问静态内部类才回去加载静态内部类.
这样就万无一失了?这时如果一个外国人看到,我想他会说:噢,天啊,这真是个糟糕的决定.
如果此刻我要用反射去创建对象,还能说万无一失吗,在反射的基础上,上面的单例全部都可以推翻?
Constructor<Singletion> constructor = Singletion.class.getDeclaredConstructor(); constructor.setAccessible(true); Singletion instance1 = constructor.newInstance(); Singletion instance2 = constructor.newInstance(); System.out.println(instance1); System.out.println(instance2);
你会惊讶的发现,两次对象创建的地址不一样,创建了两个不一样地址的对象
那么如何才能防止反射创建呢?
public class Singletion { private Singletion() { if (SingletonInside.SGT != null) { throw new RuntimeException("不允许反射创建!"); } } private static class SingletonInside{ private static final Singletion SGT=new Singletion(); } public static Singletion getInstance() { return SingletonInside.SGT; } }
这样就可以了吗?如果实现了序列化接口,我们通过序列化和反序列化还能拿到同一个对象吗?
Singletion instance = Singletion.getInstance();
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("src/main/resources/temp.txt")); oos.writeObject(instance1); oos.close(); //反序列化 ObjectInputStream ois = new ObjectInputStream( new FileInputStream("src/main/resources/temp.txt")); Singletion instance2 = (Singletion)ois.readObject();
我们通过比较地址会发现,序列化后的对象会创建另一个内存地址,我们如何防止序列化呢? readResolve方法序列化,我们就直接返回对象
public class Singletion implements Serializable { private Singletion() { if (SingletonInside.SGT != null) { throw new RuntimeException("不允许反射创建!"); } } private static class SingletonInside{ private static final Singletion SGT=new Singletion(); } public static Singletion getInstance() { return SingletonInside.SGT; } private Object readResolve(){ return SingletonInside.SGT; } }
目前单例模式还有最后一种终级方案,可以解决上述问题
public enum Singleton implements Serializable{ SGT; public void say(){ System.out.println("我是枚举单例"); } }
这种方式是 Effective Java 作者 Josh Bloch (乔什布洛赫)提倡的方式,但是无法实现延时加载,那么我们究竟该如何在实际开发中选用呢,根据业务场景选用合适的单例模式,
没有最好的单例,只有最合适的单例.下一章我们将会聊一聊简单工厂模式和抽象工厂设计模式