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

短命女 2022-12-03 15:59 89阅读 0赞

**目录**

一、单例模式的应用场景

二、常见的单例模式

饿汉式单例

懒汉式模式

反射破坏单例

反序列化破坏单例

注册时单例

ThreadLocal 单例

三、本章小结

--------------------

## 一、单例模式的应用场景 ##

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

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

## 二、常见的单例模式 ##

1.  饿汉式单例
2.  懒汉式单例
3.  注册式单例
4.  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()方法，代码如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 1][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 2][]

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

![20200905180306856.png][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 3][]

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

![20200905180831965.png][]

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

![20200905180914971.png][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 4][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 5][]

我们可以看到在 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()方法:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 6][]

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 7][]

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 8][]

在 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。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70]: /images/20221123/fba30e0d936049b6a7141c0f84cda065.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 1]: /images/20221123/827f6849975d4855beca941c7558cdb2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 2]: /images/20221123/7e3e5549eccd4d8b830fc263a2c72f0a.png
[20200905180306856.png]: /images/20221123/13391dda8e324a13992011716ec48026.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 3]: /images/20221123/71a2494636f94749ad4ca3a73000e5ef.png
[20200905180831965.png]: /images/20221123/fdbffdd4abad43a697149b182bc07362.png
[20200905180914971.png]: /images/20221123/61a05a8fdb7f4f96bb2f6bebd1c25a56.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 4]: /images/20221123/b96251abec6747a0b62b524e037f6503.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 5]: /images/20221123/47e3b554c7984b0993202a38e8118208.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 6]: /images/20221123/cdde931fffb14e11903774571d2c97b1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 7]: /images/20221123/c96c3e19cb254b72998bf1a017fd3dd6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xzNDkwNDQ3NDA2_size_16_color_FFFFFF_t_70 8]: /images/20221123/41672a71f7f6446297a45fed5ca01707.png