(面试突击宝典-设计模式) 关于单例模式你不知道的那些事

最新推荐文章于 2022-08-29 11:20:06 发布

LiMoyA

最新推荐文章于 2022-08-29 11:20:06 发布

阅读量207

点赞数

分类专栏：面试宝典-常用设计模式你不知道的那些事

本文链接：https://blog.csdn.net/ls490447406/article/details/108403058

版权

面试宝典-常用设计模式你不知道的那些事专栏收录该内容

2 篇文章 0 订阅

订阅专栏

一、单例模式的应用场景

单例模式确保一个类在任何情况下都只有一个实例，并且只提供一个全局访问点
构造方法私有(隐藏所有的构造方法

我们常用的开发框架中就有很多单例模式的应用场景，就拿最常用的Spring来说，ApplicationContext全局中就有且只有一个实例，J2EE中的ServletContext也一样。

二、常见的单例模式

饿汉式单例
懒汉式单例
注册式单例
ThreadLocal单例

饿汉式单例

饿汉式单例是在类加载的时候就立即初始化，并且创建单例对象。绝对线程安全，在线程还没出现以前就是实例化了，不可能存在访问安全问题。

优点:没有加任何的锁、执行效率比较高，在用户体验上来说，比懒汉式更好。
缺点:类加载的时候就初始化，不管用与不用都占着空间，浪费了内存，有可能占着茅坑不拉屎。

Spring的IOC中的ApplicationContext本身就是饿汉式的单例模式

public class HungrySingleton { 
    //先静态、后动态  
    //先属性、后方法
    //先上后下
    private static final HungrySingleton hungrySingleton = new HungrySingleton();

    private HungrySingleton(){} // 构造方法私有化

    public static HungrySingleton getInstance(){ 
        return hungrySingleton;
    } 
}

上图是最简单的一个饿汉式的单例模式的构造方式，还有一种方式是放在静态代码快中

// 静态代码块单例模式
public class HungryStaticSingleton {

     private static final HungryStaticSingleton hungrySingleton;    
    
     static 
     {
         hungrySingleton = new HungryStaticSingleton();
     }

     private HungryStaticSingleton(){}

     public static HungryStaticSingleton getInstance(){
         return hungrySingleton; 
     }

}

饿汉模式以上两种完全够用，适用于实例较少的模式中，如果过多会加大内存开销。

懒汉式模式

懒汉式单例的特点是:被外部类调用的时候内部类才会加载。通俗一点说就是用到我时候我才去创建。

/懒汉式单例 //在外部需要使用的时候才进行实例化 
public class LazySimpleSingleton {
    private LazySimpleSingleton(){} 
    //静态块，公共内存区域
    private static LazySimpleSingleton lazy = null; 

    public static LazySimpleSingleton  getInstance(){
        if(lazy == null){
            lazy = new LazySimpleSingleton();
        }
        return lazy; 
    }
}

然后我们书写一个线程类


    public class ExectorThread implements Runnable{ 
        @Override
        public void run() {
            LazySimpleSingleton singleton = LazySimpleSingleton.getInstance();             
            System.out.println(Thread.currentThread().getName() + ":" + singleton);
        } 
    }

测试代码

 public class LazySimpleSingletonTest { 
    public static void main(
        Thread t1 = new Thread(new ExectorThread()); 
        Thread t2 = new Thread(new ExectorThread()); 
        t1.start();
        t2.start();
        System.out.println("End"); 
    }
 }

一定几率出现创建两个不同结果的情况，意味着上面的单例存在线程安全隐患。那么，我们如何来优化代码，使得懒汉式单例在线程环境下安全呢?来看下面的代码，给 getInstance()加上 synchronized 关键字，是这个方法变成线程同步方法：

public class LazySimpleSingleton {

    private LazySimpleSingleton(){}

    //静态块，公共内存区域
    private static LazySimpleSingleton lazy = null;

    public synchronized static LazySimpleSingleton getInstance(){
        if(lazy == null){
            lazy = new LazySimpleSingleton();
        }
        return lazy; 
    }

}

但是，用 synchronized 加锁，在线程数量比较多情况下，如果 CPU 分配压力上升，会导致大批量线程出现阻塞，从而导致程序运行性能大幅下降。那么，有没有一种更好的方式，既兼顾线程安全又提升程序性能呢?答案是肯定的。我们来看双重检查锁的单例模式：

public class LazyDoubleCheckSingleton {
    private volatile static LazyDoubleCheckSingleton lazy = null;
    private LazyDoubleCheckSingleton(){}
    public static LazyDoubleCheckSingleton getInstance(){
        if(lazy == null){
            synchronized (LazyDoubleCheckSingleton.class){
                if(lazy == null){
                    lazy = new LazyDoubleCheckSingleton(); 
                } 
            }
        }
        return lazy; 
    }
}

但是，用到 synchronized 关键字，总归是要上锁，对程序性能还是存在一定影响的。难道就真的没有更好的方案吗?当然是有的。我们可以从类初始化角度来考虑，看下面的代码，采用静态内部类的方式:

//这种形式兼顾饿汉式的内存浪费，也兼顾 synchronized 性能问题 //完美地屏蔽了这两个缺点
public class LazyInnerClassSingleton {
    //默认使用 LazyInnerClassGeneral 的时候，会先初始化内部类
    //如果没使用的话，内部类是不加载的
    private LazyInnerClassSingleton(){}
    //每一个关键字都不是多余的
    //static 是为了使单例的空间共享
    //保证这个方法不会被重写，重载
    public static final LazyInnerClassSingleton getInstance(){
        //在返回结果以前，一定会先加载内部类
        return LazyHolder.LAZY; 
    }
    //默认不加载
    private static class LazyHolder{
        private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton(); 
    }
}

反射破坏单例

大家有没有发现，上面介绍的单例模式的构造方法除了加上 private 以外，没有做任何处理。如果我们使用反射来调用其构造方法，然后，再调用 getInstance()方法，应该就会两个不同的实例。现在来看一段测试代码，以 LazyInnerClassSingleton 为例

public class LazyInnerClassSingletonTest { 
    public static void main(String[] args) {
        try{
            //很无聊的情况下，进行破坏
            Class<?> clazz = LazyInnerClassSingleton.class;
            //通过反射拿到私有的构造方法
            Constructor c = clazz.getDeclaredConstructor(null); 
            //强制访问，强吻，不愿意也要吻
            c.setAccessible(true);
            //暴力初始化
            Object o1 = c.newInstance();
            //调用了两次构造方法，相当于 new 了两次 //犯了原则性问题，
            Object o2 = c.newInstance();
            System.out.println(o1 == o2); 
        }catch (Exception e){
             e.printStackTrace();
        } 
    }
}

答案肯定是 false，现在，我们在其构造方法中做一些限制，一旦出现多次重复创建，则直接抛出异常。来看优化后的代码:

//史上最牛 B 的单例模式的实现方式
public class LazyInnerClassSingleton {
        //默认使用 LazyInnerClassGeneral 的时候，会先初始化内部类 
        //如果没使用的话，内部类是不加载的
        private LazyInnerClassSingleton(){
            if(LazyHolder.LAZY != null){
                throw new RuntimeException("不允许创建多个实例");
            }
        }
        //每一个关键字都不是多余的
        //static 是为了使单例的空间共享
        //保证这个方法不会被重写，重载
        public static final LazyInnerClassSingleton getInstance(){
            //在返回结果以前，一定会先加载内部类
            return LazyHolder.LAZY; 
        }
        //默认不加载
        private static class LazyHolder{
            private static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton(); 
        }
}

反序列化破坏单例

当我们将一个单例对象创建好，有时候需要将对象序列化然后写入到磁盘，下次使用时再从磁盘中读取到对象，反序列化转化为内存对象。反序列化后的对象会重新分配内存，即重新创建。那如果序列化的目标的对象为单例对象，就违背了单例模式的初衷，相当于破坏了单例，来看一段代码:

//反序列化时导致单例破坏
public class SeriableSingleton implements Serializable {
    public final static SeriableSingleton INSTANCE = new SeriableSingleton(); 
    private SeriableSingleton(){}
    public static SeriableSingleton getInstance()
    { 
        return INSTANCE;
    } 
}

public class SeriableSingletonTest {
    public static void main(String[] args) {
        SeriableSingleton s1 = null;
        SeriableSingleton s2 = SeriableSingleton.getInstance();
        FileOutputStream fos = null; 
        try {
        fos = new FileOutputStream("SeriableSingleton.obj"); 
        ObjectOutputStream oos = new ObjectOutputStream(fos); 
        oos.writeObject(s2);
        oos.flush();
        oos.close();

        FileInputStream fis = new FileInputStream("SeriableSingleton.obj");                     
        ObjectInputStream ois = new ObjectInputStream(fis);
        s1 = (SeriableSingleton)ois.readObject();
        ois.close();
        System.out.println(s1); 
        System.out.println(s2); 
        System.out.println(s1 == s2);
        } catch (Exception e)
        { 
           e.printStackTrace();
        } 
     }
}

运行结果中，反序列化后的对象和手动创建的对象是不一致的，实例化了两次，违背了单例的设计初衷。那么，我们如何保证序列化的情况下也能够实现单例?其实很简单，只需要增加 readResolve()方法即可。来看优化代码:

public class SeriableSingleton implements Serializable {
    public final static SeriableSingleton INSTANCE = new SeriableSingleton(); 
    private SeriableSingleton(){}
    public static SeriableSingleton getInstance(){ 
        return INSTANCE;
    }
    private Object readResolve(){
        return INSTANCE; 
    }
}

那么，为什么这样就能解决返序列化破坏单例呢，我们一起看JDK源码来寻找答案：

ObjectInputStream 类的 readObject()方法，代码如下：

我们发现在 readObject 中又调用了我们重写的 readObject0()方法。进入 readObject0() 方法，代码如下:

我们看到 TC_OBJECTD 中判断，调用了 ObjectInputStream 的 readOrdinaryObject() 方法，我们继续进入看源码:

发现调用了 ObjectStreamClass 的 isInstantiable()方法，而 isInstantiable()里面的代码如下:

很简单，就是判断当前是否包含无参构造，如果存在就会被实例化，其实还没有找到为什么加上 readResolve()方法就避免了单例被破坏的真正原因。我再回到 ObjectInputStream 的 readOrdinaryObject()方法继续往下看：

判断无参构造方法是否存在之后，又调用了 hasReadResolveMethod()方法，来看代码:

逻辑非常简单，就是判断 readResolveMethod 是否为空，不为空就返回 true。那么 readResolveMethod 是在哪里赋值的呢?通过全局查找找到了赋值代码在私有方法 ObjectStreamClass()方法中给 readResolveMethod 进行赋值，来看代码:

上面的逻辑其实就是通过反射找到一个无参的 readResolve()方法，并且保存下来。现在再回到 ObjectInputStream 的 readOrdinaryObject() 方法继续往下看，如果 readResolve()存在则调用 invokeReadResolve()方法，来看代码:

我们可以看到在 invokeReadResolve()方法中用反射调用了 readResolveMethod 方法。通过 JDK 源码分析我们可以看出，虽然，增加 readResolve()方法返回实例，解决了单例被破坏的问题。但是，我们通过分析源码以及调试，我们可以看到实际上实例化了两次，只不过新创建的对象没有被返回而已。那如果，创建对象的动作发生频率增大，就意味着内存分配开销也就随之增大，难道真的就没办法从根本上解决问题吗?下面我们来注册式单例也许能帮助到你。

注册式单例

注册式单例又称为登记式单例，就是将每一个实例都登记到某一个地方，使用唯一的标识获取实例。注册式单例有两种写法:一种为容器缓存，一种为枚举登记。先来看枚举式单例的写法，来看代码，创建 EnumSingleton 类

public enum EnumSingleton {
     INSTANCE;
     private Object data; 
     public Object getData() {
       return data;
     }
     public void setData(Object data) 
     { 
        this.data = data;
     }
     public static EnumSingleton getInstance()
     {
         return INSTANCE; 
     }
}

那么，枚举类是如何实现单例的呢，我们需要反编译其的class文件进行查看，如下：

static {
     INSTANCE = new EnumSingleton("INSTANCE", 0);
     $VALUES = (new EnumSingleton[] { INSTANCE });
}

原来，枚举式单例在静态代码块中就给 INSTANCE 进行了赋值，是饿汉式单例的实现。至此，我们还可以试想，序列化我们能否破坏枚举式单例呢?我们不妨再来看一下 JDK 源码，还是回到 ObjectInputStream 的 readObject0()方法:

我们看到在 readObject0()中调用了 readEnum()方法，来看 readEnum()中代码实现:

我们发现枚举类型其实通过类名和 Class 对象类找到一个唯一的枚举对象。因此，枚举对象不可能被类加载器加载多次。那么反射是否能破坏枚举式单例呢?

还是习惯性地想来看看 JDK 源码，进入 Constructor 的 newInstance()方法:

在 newInstance()方法中做了强制性的判断，如果修饰符是 Modifier.ENUM 枚举类型，直接抛出异常。到这为止，我们是不是已经非常清晰明了呢?枚举式单例也是《Effective Java》书中推荐的一种单例实现写法。在 JDK 枚举的语法特殊性，以及反射也为枚举保驾护航，让枚举式单例成为一种比较优雅的实现。

接下来看注册式单例还有另一种写法，容器缓存的写法，创建 ContainerSingleton 类:

public class ContainerSingleton {
     private ContainerSingleton(){}
     private static Map<String,Object> ioc = new ConcurrentHashMap<String,Object>();   
     public static Object getBean(String className){
        synchronized (ioc) {
        if (!ioc.containsKey(className)) {
               Object obj = null;
               try {
                   obj = Class.forName(className).newInstance();
                   ioc.put(className, obj); 
               } catch (Exception e) {
                  e.printStackTrace();
               }
                   return obj;
               } else {
                   return ioc.get(className); 
               }
        } 
    }
}

容器式写法适用于创建实例非常多的情况，便于管理。但是，是非线程安全的。

ThreadLocal 单例

public class ThreadLocalSingleton {
    private static final ThreadLocal<ThreadLocalSingleton> threadLocalInstance =
        new ThreadLocal<ThreadLocalSingleton>(){ 
            @Override
            protected ThreadLocalSingleton initialValue() { 
                return new ThreadLocalSingleton();
            } 
        };
    private ThreadLocalSingleton(){}
    public static ThreadLocalSingleton getInstance(){ 
        return threadLocalInstance.get();
    }
 }

在主线程 main 中无论调用多少次，获取到的实例都是同一个，都在子线程中分别获取到了不同的实例。那么 ThreadLocal 是如果实现这样的效果的呢?我们知道上面的单例模式为了达到线程安全的目的，给方法上锁，以时间换空间。ThreadLocal 将所有的对象全部放在 ThreadLocalMap 中，为每个线程都提供一个对象，实际上是以空间换时间来实现线程间隔离的。

三、本章小结

单例模式可以保证内存里只有一个实例，减少了内存开销;可以避免对资源的多重占用。单例模式看起来非常简单，实现起来其实也非常简单。但是在面试中却是一个高频面试题。希望小伙伴们通过本章的学习，对单例模式有非常深刻的掌握，在面试中彰显技术深度，提升核心竞争力，给面试加分，顺利拿到 Offer。

LiMoyA

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
(面试突击宝典-设计模式) 关于单例模式你不知道的那些事

一、单例模式的应用场景单例模式确保一个类在任何情况下都只有一个实例，并且只提供一个全局访问点构造方法私有(隐藏所有的构造方法我们常用的开发框架中就有很多单例模式的应用场景，就拿最常用的Spring来说，ApplicationContext全局中就有且只有一个实例，J2EE中的ServletContext也一样。二、常见的单例模式饿汉式单例懒汉式单例注册式单例 ThreadLocal单例饿汉式单例...
复制链接

扫一扫

专栏目录