Java单例模式与破坏单例模式概念原理深入讲解

 更新时间:2023年02月21日 10:34:33   作者:绿仔牛奶_  
单例模式(Singleton Pattern)是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类,该类负责创建自己的对象,同时确保只有单个对象被创建

什么是单例模式

经典设计模式又分23种,也就是GoF 23 总体分为三大类:

  • 创建型模式
  • 结构性模式
  • 行为型模式

Java中单例模式是一种常见的设计模式,单例模式的写法有好几种,这里主要介绍三种:懒汉式单例、饿汉式单例、登记式单例。

单例模式有以下特点:

  • 单例类只能有一个实例。
  • 单例类必须自己创建自己的唯一实例。
  • 单例类必须给所有其他对象提供这一实例。

  单例模式确保某个类只有一个实例,而且自行实例化并向整个系统提供这个实例。在计算机系统中,线程池、缓存、日志对象、对话框、打印机、显卡的驱动程序对象常被设计成单例。这些应用都或多或少具有资源管理器的功能。每台计算机可以有若干个打印机,但只能有一个Printer Spooler,以避免两个打印作业同时输出到打印机中。每台计算机可以有若干通信端口,系统应当集中管理这些通信端口,以避免一个通信端口同时被两个请求同时调用。总之,选择单例模式就是为了避免不一致状态。

饿汉式(预加载)

饿汉式单例: 在类加载时,就会创建好将会使用的对象,可能会造成内存的浪费

示例:

public class Hungry {
    // 创建唯一实例
    private final static Hungry HUNGRY = new Hungry();
    private Hungry(){}
	// 全局访问点 ---> 拿到HUNGRY实例
    public static Hungry getIntance(){
        return HUNGRY;
    }
}

而预加载就是先一步加载,我们没有使用该单例对象但是已经将其加载到内存中,那么就会造成内存的浪费

懒汉式(懒加载)

懒汉式改善了饿汉式浪费内存的问题,等到需要用到实例的时候再去加载到内存中

懒汉式写法( 线程不安全 ):

public class LazyMan {
    private LazyMan(){}
    public static LazyMan lazyMan;
    public static LazyMan getInstance(){
        if (lazyMan==null){
           lazyMan = new LazyMan();
        }
        return lazyMan;
    }
}

但是在不进行任何同步干预的情况下,懒汉式不是线程安全的单例模式,经典的解决方案就是利用双重检验锁保证程序的原子性有序性,如下示例:

public class LazyMan {
    private LazyMan(){}
    // 懒汉当中的双重检验锁 --> 可以保证线程安全
    public volatile static LazyMan lazyMan;
    // volatile 保证了new实例时不会发生指令重排
    public static LazyMan getInstance(){
        if (lazyMan==null){
            synchronized (LazyMan.class){
                // 此处上锁  以保证原子操作
                if (lazyMan == null){
                    lazyMan = new LazyMan();
                }
            }
        }
        return lazyMan;
    }
}

反射破坏单例模式

反射是一种动态获取类资源的一种途径,我们让然可以通过反射来获取单例模式中的更多实例:

public class LazyMan {
    // 空参构造器
    private LazyMan(){}
    // 懒汉当中的双重检验锁 --> 可以保证线程安全
    public volatile static LazyMan lazyMan;
    // volatile 保证了new实例时不会发生指令重排
    public static LazyMan getInstance(){
        if (lazyMan==null){
            synchronized (LazyMan.class){
                // 此处上锁  以保证原子操作
                if (lazyMan == null){
                    lazyMan = new LazyMan();// 不是原子操作
                }
            }
        }
        return lazyMan;
    }
    public static void main(String[] args) throws Exception{
        // 获取无参构造器
        Constructor<LazyMan> constructor = LazyMan.class.getDeclaredConstructor(null);
        constructor.setAccessible(true);// 无视私有
        // 获取实例
        LazyMan instance2 = constructor.newInstance();
        LazyMan instance3 = constructor.newInstance();
        LazyMan instance4 = constructor.newInstance();
        // 懒汉式单例 获取唯一实例
        LazyMan instance = LazyMan.getInstance();
        System.out.println("getIntance获取实例(1)hashCode:"+instance.hashCode());
        System.out.println("反射构造器newIntance获取实例(2)hashCode:"+instance2.hashCode());
        System.out.println("反射构造器newIntance获取实例(3)hashCode:"+instance3.hashCode());
        System.out.println("反射构造器newIntance获取实例(4)hashCode:"+instance4.hashCode());
    }
}

上述程序输出结果如下:

/*
getIntance获取实例(1)hashCode:895328852
反射构造器newIntance获取实例(2)hashCode:1304836502
反射构造器newIntance获取实例(3)hashCode:225534817
反射构造器newIntance获取实例(4)hashCode:1878246837
*/

修复方式1:

// 对空参构造器进行上锁 并对唯一实例lazyman判断是否已经初始化
 private LazyMan(){
    if (lazyMan != null){
		throw new RuntimeException("不要试图破坏单例模式");
    }
 }

但是这种修复方式仍然会被破坏,我们首先是利用了反射来获取LazyMan的空参构造器,并利用其构造器进行初始化获取实例,但是如果我们一直不调用getIntance方法来初始化lazyman实例而一直用反射获取,那么这种方式就形同虚设

因此,得出下一个修复方式。我们依然对空参构造器进行上锁,然后利用标志位保证我们的空参构造器只能使用一次,也就是最多只能为一个实例进行初始化。

修复方式2:

// 解决2.  对空参构造器进行上锁  利用标志位保证空参构造器只能初始化一次实例  但是标志位字段仍可以通过其他途径被拿到  并且修改
    private static boolean flag = false;
	private LazyMan(){
        synchronized(LazyMan.class){
            if (flag == false){
                flag = true;
            }else {
                throw new RuntimeException("不要试图破坏单例模式");
            }
        }
    }

上述代码所示,利用flag作为标志位来保证空参构造器只能对最多一个实例执行初始化操作。但是,同时我们所设置的标志位flag同样存在被通过各种渠道拿到的风险,比如反编译。拿到flag标志后就可以对其修改,示例:

public static void main(String[] args) throws Exception{
        // 获取无参构造器
        Constructor<LazyMan> constructor = LazyMan.class.getDeclaredConstructor(null);
        constructor.setAccessible(true);// 无视私有
        // 懒汉式单例 获取唯一实例
        LazyMan instance = LazyMan.getInstance();  // (1)
        // 获取标志位字段并进行修改
        Field flag1 = LazyMan.class.getDeclaredField("flag");
        // (1) 处已经调用了空参构造器  flag变为true  此处修改为false 可以继续创建实例
        flag1.set(instance,false);
        LazyMan instance2 = constructor.newInstance();
        // 与上述同理
        flag1.set(instance2,false);
        LazyMan instance3 = constructor.newInstance();
        System.out.println("getIntance获取实例(1)hashCode:"+instance.hashCode());
        System.out.println("反射构造器newIntance获取实例(2)hashCode:"+instance2.hashCode());
        System.out.println("反射构造器newIntance获取实例(3)hashCode:"+instance3.hashCode());
    }

那么既然如此,是不是单例程序无论如何设计最终都会被反射破坏呢?

事实并非如此,我们打开反射得到的构造器.newInstance方法源码查看:

// 我们只看如下两行
if ((clazz.getModifiers() & Modifier.ENUM) != 0)
            throw new IllegalArgumentException("Cannot reflectively create enum objects");

如上述代码所示,Java给出的解释为:

如果实际参数和形式参数的数量不同;如果原始参数的展开转换失败;或者如果在可能展开之后,参数值不能通过方法调用转换转换为相应的形式参数类型;如果此构造函数属于枚举类型。符合上述任一情况将会抛出IllegalArgumentException("Cannot reflectively create enum objects")非法参数异常

也就是说,枚举类型是可以避免单例模式被破坏的

public enum enumSingle {
    INSTANCE;
    public enumSingle getInstance() {
        return INSTANCE;
    }
}
class TestEnumSingle{
    public static void main(String[] args) throws Exception {
        // 下面我们尝试用反射来破坏枚举类
        // 枚举类的构造器实际上带有两个参数 String和int
        Constructor<enumSingle> declaredConstructor = enumSingle.class.getDeclaredConstructor(String.class,int.class);
        declaredConstructor.setAccessible(true);
        // 直接获取实例
        enumSingle instance = enumSingle.INSTANCE;
        // 反射获取实例
        enumSingle enumSingle1 = declaredConstructor.newInstance();
        System.out.println("类名直接访问获取实例hashCode:"+instance.hashCode());
        System.out.println("反射实例hashCode:"+enumSingle1.hashCode());
    }
}
// 最终抛出  java.lang.IllegalArgumentException: Cannot reflectively create enum objects

除了反射会打破单例之外,序列化Serializable也同样会破坏单例模式,具体体现是物品们同一对象在序列化前和反序列化之后不是同一对象

到此这篇关于Java单例模式与破坏单例模式概念原理深入讲解的文章就介绍到这了,更多相关Java单例模式内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • SpringBoot中@RestControllerAdvice注解的使用

    SpringBoot中@RestControllerAdvice注解的使用

    这篇文章主要介绍了SpringBoot中@RestControllerAdvice注解的使用,@RestControllerAdvice主要用精简客户端返回异常,它可以捕获各种异常,需要的朋友可以参考下
    2024-01-01
  • 6个必备的Java并发面试种子题目合集

    6个必备的Java并发面试种子题目合集

    并发是Java面试的经常会考到的知识点,这篇文章主要为大家整理了6个必备的Java并发面试种子题目,文中的示例代码简洁易懂,需要的可以学习一下
    2023-07-07
  • 在springboot中使用拦截器的步骤详解

    在springboot中使用拦截器的步骤详解

    拦截器Interceptor,是SpringMVC中的核心内容,在SpringBoot中使用Interceptor,同时采用全注解开发,这篇文章主要介绍了在springboot中使用拦截器的步骤,需要的朋友可以参考下
    2022-01-01
  • java设计模式:建造者模式之生产线

    java设计模式:建造者模式之生产线

    这篇文章主要介绍了Java设计模式之建造者模式,结合具体实例形式分析了建造者模式的概念、原理、实现方法与相关使用注意事项,需要的朋友可以参考下
    2021-08-08
  • SpringBoot中@ConditionalOnBean实现原理解读

    SpringBoot中@ConditionalOnBean实现原理解读

    这篇文章主要介绍了SpringBoot中@ConditionalOnBean实现原理,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-02-02
  • SpringMVC中@RequestMapping注解的实现

    SpringMVC中@RequestMapping注解的实现

    RequestMapping是一个用来处理请求地址映射的注解,本文主要介绍了SpringMVC中@RequestMapping注解的实现,具有一定的参考价值,感兴趣的可以了解一下
    2024-01-01
  • Java类加载器ClassLoader源码层面分析讲解

    Java类加载器ClassLoader源码层面分析讲解

    ClassLoader翻译过来就是类加载器,普通的java开发者其实用到的不多,但对于某些框架开发者来说却非常常见。理解ClassLoader的加载机制,也有利于我们编写出更高效的代码。ClassLoader的具体作用就是将class文件加载到jvm虚拟机中去,程序就可以正确运行了
    2022-09-09
  • java基础开发泛型类的详解

    java基础开发泛型类的详解

    这篇文章为大家介绍了java基础开发中泛型类的详解,包括泛型的概念以及应用实例有需要的朋友可以借鉴参考下,希望能够有所帮助
    2021-10-10
  • springboot之SpringApplication生命周期和事件机制解读

    springboot之SpringApplication生命周期和事件机制解读

    这篇文章主要介绍了springboot之SpringApplication生命周期和事件机制,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2023-06-06
  • Java Socket+mysql实现简易文件上传器的代码

    Java Socket+mysql实现简易文件上传器的代码

    最近在做一个小项目,项目主要需求是实现一个文件上传器,通过客户端的登陆,把本地文件上传到服务器的数据库(本地的)。下面通过本文给大家分享下实现代码,感兴趣的朋友一起看看吧
    2016-10-10

最新评论