设计模式- 饿汉式单例与懒汉式单例

最新推荐文章于 2022-04-03 11:33:35 发布

寻找那道光

最新推荐文章于 2022-04-03 11:33:35 发布

阅读量167

点赞数

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.csdn.net/weixin_41300437/article/details/104507459

版权

设计模式专栏收录该内容

21 篇文章 0 订阅

订阅专栏

1. 单例模式应用场景

单例模式（Singleton Pattern）是指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。单例模式是创建型模式。单例模式在现实生活中应用也非常广泛。例如，国家主席、公司 CEO、部门经理等。在 J2EE 标准中，ServletContext、 ServletContextConfig 等；在 Spring 框架应用中 ApplicationContext；数据库的连接池也都是单例形式。

2. 饿汉式单例

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

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

package com.gupaoedu.vip.pattern.singleton.hungry;

/**
 * 饿汉式单例模式三要素
 * 1.构造方法私有
 * 2.静态的获取单例的方法
 * 3.实例在类加载还未被初始化的时候就创建了  private static final
 * 写在静态块里面也可以
 * 缺点:不管用不用,都实例化,会浪费内存空间===>改进:懒汉式单例
 */
public class HungrySingleton {

//    private static final HungrySingleton  hungrySingleton= new HungrySingleton();
    private static final HungrySingleton hungrySingleton;
    static {
        hungrySingleton= new HungrySingleton();
    }
    private HungrySingleton(){}

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

3. 懒汉式单例

懒汉式单例的特点是：在外部需要使用的时候才进行实例化，代码如下：

package com.gupaoedu.vip.pattern.singleton.lazy;

/**
 * 1.构造方法私有化
 * 2.提供全局访问点
 */
public class LazySimpleSingleton {
    private  static  LazySimpleSingleton lazy;

    private LazySimpleSingleton(){}

    public static LazySimpleSingleton getInstance(){
        if(null == lazy) { //在这里加断点调试
            lazy = new LazySimpleSingleton();
        }
        return lazy;
    }
}

测试：

package com.gupaoedu.vip.pattern.singleton.lazy;

public class LazySimpleSingletonTest {
    public static void main(String[] args) {
        new Thread(new ExexutorThread()).start();
        new Thread(new ExexutorThread()).start();

    }
}

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

很显然，单例被破坏了，具体破坏过程，可以参考IDEA环境下的多线程调试方式一文
在这里插入图片描述
那么怎么去避免单例被破坏呢？其实很简单，加锁即可：

package com.gupaoedu.vip.pattern.singleton.lazy;

/**
 * 1.构造方法私有化
 * 2.提供全局访问点
 */
public class LazySimpleSingleton {
    private  static  LazySimpleSingleton lazy;

    private LazySimpleSingleton(){}

  /*  public static LazySimpleSingleton getInstance(){
        if(null == lazy) { //在这里加断点调试
            lazy = new LazySimpleSingleton();
        }
        return lazy;
    }*/
  public synchronized static LazySimpleSingleton getInstance() {
      if (null == lazy) { //在这里加断点调试
          lazy = new LazySimpleSingleton();
      }
      return lazy;
  }

}

这时候再来调试，当其中一个线程执行并调用 getInstance()方法时，另一个线程在调用 getInstance()方法，线程的状态由 RUNNING 变成了 MONITOR,出现阻塞。直到第一个线程执行完，第二个线程才恢复 RUNNING 状态继续调用 getInstance() 方法。如下图所示：
在这里插入图片描述

线程安全的问题便解决了。但是，用 synchronized对getInstance() 加锁，在线程数量比较多情况下，如果 CPU 分配压力上升，会导致大批量线程出现阻塞，从而导致程序运行性能大幅下降。那么，有没有一种更好的方式，既兼顾线程安全又提升程序性能呢, 就是双重检查锁的单例模式了

4. 双重检查锁单例模式

package com.gupaoedu.vip.pattern.singleton.lazy;

public class LazyDoubleCheckSingleton  {
    //加上volatile关键字,保证线程可见性
    private /*volatile*/ static  LazyDoubleCheckSingleton lazy;

    private LazyDoubleCheckSingleton(){}

    //synchronized是一种类锁,在这里把加锁放到if里面去
    public  static LazyDoubleCheckSingleton getInstance(){
        if(null == lazy) { //在这里加断点调试
            synchronized(LazyDoubleCheckSingleton.class){
                if(null == lazy) { //这里如果不加判断,第二个线程还是会有可能再new一次对象
                    lazy = new LazyDoubleCheckSingleton();
                }
            }
        }
        return lazy;
    }
}

测试类：

package com.gupaoedu.vip.pattern.singleton.lazy;

public class LazyDoubleCheckSimpleSingletonTest {
    public static void main(String[] args) {
        Thread t1 = new Thread(new ExecutorThreadDoubleCheck());
        Thread t2 = new Thread(new ExecutorThreadDoubleCheck());
        t1.start();
        t2.start();
        System.out.println("Executor end"); //此处加断点
    }
}

class ExecutorThreadDoubleCheck implements Runnable {

    @Override
    public void run() {
        LazyDoubleCheckSingleton singleton = LazyDoubleCheckSingleton.getInstance(); //在这里 加断点
        System.out.println(Thread.currentThread().getName() + singleton);
    }
}

为什么双重加锁检查单例，要判断两次呢，我们把synchronized 锁住的代码块中的if判断去掉，debug调试2个线程，结果发现，还是会生成两个实例。为什么呢？如果没又里面一层的判断，会存在这样一种情况，第一个线程判断lazy为null，还未获得锁时，第二个线程也进入到外层的if判断，如果恰好此时第一个线程获得锁，那么第二个线程将等待，第一个线程执行完，产生一个实例，将锁释放，第二个线程获得锁将程序执行完并返回第二个实例，结果就是如下，产生了两个实例，单例依旧被破坏，因此内层的第二次判空不可缺少！
在这里插入图片描述

4.1.反射破坏双重检查锁单例

虽然双重检查锁单例模式一定程度上兼顾了线程安全和程序性能，但是依旧能被暴力反射破坏单例，运行下面的代码：

package com.gupaoedu.vip.pattern.singleton.lazy;

import java.lang.reflect.Constructor;

public class LazyDoubleCheckSingletonReflectTest {
    public static void main(String[] args) throws Exception {
        Class<LazyDoubleCheckSingleton> clazz = LazyDoubleCheckSingleton.class;
        Constructor<LazyDoubleCheckSingleton> c = clazz.getDeclaredConstructor(null);
        c.setAccessible(true); //强制访问
        LazyDoubleCheckSingleton o1 = c.newInstance();
        LazyDoubleCheckSingleton o2 = LazyDoubleCheckSingleton.getInstance();
        System.out.println(o1);
        System.out.println(o2);
        System.out.println(o1 == o2); //结果为false ,说明单例被破坏,实例化了两次
    }
}

可以看到，反射获取的实例跟getInstance()方法获取的不是同一个实例，说明反射确实能够破坏单例。
在这里插入图片描述

5. 静态内部类单例

用到 synchronized 关键字，总归是要上锁，对程序性能还是存在一定影响的。我们可以从类初始化角度来考虑，看下面代码，采用静态内部类的方式，这种形式兼顾饿汉式的内存浪费，也兼顾 synchronized 性能问题。内部类一定是要在方法调用之前初始化，巧妙地避免了线程安全问题。

package com.gupaoedu.vip.pattern.singleton.lazy;

public class LazyInnerClassSingleton {
    /**
     * 即便使用了静态内部类,调用者仍可以通过反射机制以及序列化和反序列化来暴力 破坏单例,这里需要加判断来阻止
     */
    private LazyInnerClassSingleton(){ }

    /**
     * 利用内部类的特性,JVM底层 的执行逻辑,避免了线程安全问题
     * LazyHolder里面的逻辑需要等到外部方法调用时才执行,
     * @return
     */
    public static final LazyInnerClassSingleton getInstance(){
        return LazyHolder.LAZY;
    }

    private static  class  LazyHolder{
        private  static final LazyInnerClassSingleton LAZY = new LazyInnerClassSingleton();
    }
}

5.1 反射破坏内部类单例

通过暴力反射，静态内部类单例也是可以被破坏的，因为它的构造方法除了加上 private 以外没有做任何处理。如果我们使用反射来调用其构造方法，然后，再调用 getInstance()方法，就会得到两个不同的实例。如下代码，执行返回false, 说明两个对象不是同一个实例。

package com.gupaoedu.vip.pattern.singleton.lazy;

import java.lang.reflect.Constructor;

public class LazyInnerClassSingletonReflectTest {
    public static void main(String[] args) throws Exception {

        Class<LazyInnerClassSingleton> clazz = LazyInnerClassSingleton.class;
        Constructor<LazyInnerClassSingleton> c = clazz.getDeclaredConstructor(null);
        c.setAccessible(true); //强制访问
        LazyInnerClassSingleton o1 = c.newInstance();
        LazyInnerClassSingleton o2 = c.newInstance();
//        LazyInnerClassSingleton o2 = LazyInnerClassSingleton.getInstance();
        System.out.println(o1 == o2); //结果为false ,,说明单例被破坏,实例化了两次
    }

}

解决办法：在其构造方法中做一些限制，一旦出现重复创建，则直接抛出异常：

private LazyInnerClassSingleton(){
       if (LazyHolder.LAZY != null){
            throw  new RuntimeException("不允构建多个实例!");
        }

}

测试结果如下：
在这里插入图片描述

5.2 序列化破坏单例

当我们将一个单例对象创建好，有时候需要将对象序列化然后写入到磁盘，下次使用时再从磁盘中读取到对象，反序列化转化为内存对象。反序列化后的对象会重新分配内存，即重新创建。那如果序列化的目标的对象为单例对象，就破坏了单例。写一个饿汉式单例，然后测试序列化破坏单例：

package com.gupaoedu.vip.pattern.singleton.seriable;

import java.io.Serializable;

public class SerializableSingleton implements Serializable {

    private static final SerializableSingleton INSTANCE = new SerializableSingleton();//饿汉式单例

    private SerializableSingleton(){    }

    public static  SerializableSingleton getInstance(){
        return INSTANCE;
    }
}

测试类：

package com.gupaoedu.vip.pattern.singleton.seriable;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class SerializableSingletonTest {
    public static void main(String[] args) {
        SerializableSingleton s1 = null;
        SerializableSingleton s2 = SerializableSingleton.getInstance();
        FileOutputStream fos = null;
        try {
            fos = new FileOutputStream("SerializableSingleton1.obj")
            ;
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            //序列化，写入磁盘
            oos.writeObject(s2);
            oos.flush();
            oos.close();
            FileInputStream fis = new FileInputStream("SerializableSingleton1.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            //反序列化，从磁盘读取并转换为Java对象
            s1 = (SerializableSingleton)ois.readObject();
            System.out.println(s1);
            System.out.println(s2);
            System.out.println(s1 == s2);
            
        } catch (Exception e){
            e.printStackTrace();
        }

    }
}

结果说明，序列化也是会破坏单例的：
在这里插入图片描述
解决办法：重写readResolve()方法

package com.gupaoedu.vip.pattern.singleton.seriable;
import java.io.Serializable;

public class SerializableSingleton implements Serializable {

    private static final SerializableSingleton INSTANCE = new SerializableSingleton();//饿汉式单例
    private SerializableSingleton(){   }
    public static  SerializableSingleton getInstance(){
        return INSTANCE;
    }

    //重写readResolve()方法只不过是覆盖了反序列号出来的对象，还是创建了2次，发生在JVM层面，之前反序列化出来的对象会被GC
    private Object readResolve(){
        return INSTANCE;
    }

}

结果如下：
在这里插入图片描述
分析。从ois.readObject();入手

private Object readObject0(boolean unshared) throws IOException {
    boolean oldMode = bin.getBlockDataMode();
    if (oldMode) {
        int remain = bin.currentBlockRemaining();
        if (remain > 0) {
            throw new OptionalDataException(remain);
        } else if (defaultDataEnd) {
            /*
             * Fix for 4360508: stream is currently at the end of a field
             * value block written via default serialization; since there
             * is no terminating TC_ENDBLOCKDATA tag, simulate
             * end-of-custom-data behavior explicitly.
             */
            throw new OptionalDataException(true);
        }
        bin.setBlockDataMode(false);
    }

    byte tc;
    while ((tc = bin.peekByte()) == TC_RESET) {
        bin.readByte();
        handleReset();
    }

    depth++;
    totalObjectRefs++;
    try {
        switch (tc) {
            case TC_NULL:
                return readNull();

            case TC_REFERENCE:
                return readHandle(unshared);

            case TC_CLASS:
                return readClass(unshared);

            case TC_CLASSDESC:
            case TC_PROXYCLASSDESC:
                return readClassDesc(unshared);

            case TC_STRING:
            case TC_LONGSTRING:
                return checkResolve(readString(unshared));

            case TC_ARRAY:
                return checkResolve(readArray(unshared));

            case TC_ENUM:
                return checkResolve(readEnum(unshared));

            case TC_OBJECT:
                return checkResolve(readOrdinaryObject(unshared));

            case TC_EXCEPTION:
                IOException ex = readFatalException();
                throw new WriteAbortedException("writing aborted", ex);

            case TC_BLOCKDATA:
            case TC_BLOCKDATALONG:
                if (oldMode) {
                    bin.setBlockDataMode(true);
                    bin.peek();             // force header read
                    throw new OptionalDataException(
                        bin.currentBlockRemaining());
                } else {
                    throw new StreamCorruptedException(
                        "unexpected block data");
                }

            case TC_ENDBLOCKDATA:
                if (oldMode) {
                    throw new OptionalDataException(true);
                } else {
                    throw new StreamCorruptedException(
                        "unexpected end of block data");
                }

            default:
                throw new StreamCorruptedException(
                    String.format("invalid type code: %02X", tc));
        }
    } finally {
        depth--;
        bin.setBlockDataMode(oldMode);
    }

上面代码中有一个分支
在这里插入图片描述

显然是有构造方法的,不管这个构造方法是私有还是公有,都会初始化

判断如果有readResolve方法,就调用该方法,那么可以在readResolve方法里面直接返回我们之前创建好的实例即可

这样设计是JDK考虑到单例被破坏的情况,是一种亡羊补牢的方式,重写readResolve()方法只不过是覆盖了反序列号出来的对象,实际上还是创建了2次,但是发生在JVM层面，相对来说比较安全，之前反序列化出来的对象会被GC。

寻找那道光

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
设计模式- 饿汉式单例与懒汉式单例

1. 单例模式应用场景单例模式（Singleton Pattern）是指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。单例模式是创建型模式。单例模式在现实生活中应用也非常广泛。例如，国家主席、公司 CEO、部门经理等。在 J2EE 标准中，ServletContext、 ServletContextConfig 等；在 Spring 框架应用中 ApplicationCont...
复制链接

扫一扫

专栏目录