后端---Java设计模式之单例模式详解

一、单例模式定义

单例模式确保某个类只有一个实例,而且自行实例化并向整个系统提供这个实例。

二、为什么要使用单例模式

1.对于系统中的某些类来说,只有一个实例很重要。例如,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;售票时,一共有100张票,可有有多个窗口同时售票,但需要保证不要超售(这里的票数余量就是单例,售票涉及到多线程)。如果不是用机制对窗口对象进行唯一化将弹出多个窗口,如果这些窗口显示的都是相同的内容,重复创建就会浪费资源。

2.有些类如果不控制成单例的结构,应用中就会存在很多一模一样的类实例,这会非常浪费系统的内存资源,而且容易导致错误甚至一定会产生错误,所以我们单例模式所期待的目标或者说使用它的目的,是为了尽可能的节约内存空间,减少无谓的GC消耗,并且使应用可以正常运作。

三、什么时候使用单例模式

1.我们可以发现所有可以使用单例模式的类都有一个共性,那就是这个类没有自己的状态,换句话说,这些类无论你实例化多少个,其实都是一样的。

2.在应用中如果有两个或者两个以上的实例会引起错误,又或者我换句话说,就是这些类,在整个应用中,同一时刻,有且只能有一种状态。

应用场景:

需求:在前端创建工具箱窗口,工具箱要么不出现,出现也只出现一个

遇到问题:每次点击菜单都会重复创建“工具箱”窗口。

解决方案一:使用if语句,在每次创建对象的时候首先进行判断是否为null,如果为null再创建对象。

需求:如果在5个地方需要实例出工具箱窗体

遇到问题:这个小bug需要改动5个地方,并且代码重复,代码利用率低

解决方案二:利用单例模式,保证一个类只有一个实例,并提供一个访问它的全局访问点。

四、常见的两种单利模式(懒汉式饿汉式) 

 汉式单例类:在对象初始化时,才生成实例化

 饿汉式单例类:在类初始化时,已经自行实例化

单例模式有以下特点:  

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

目的

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

2:懒汉式

先把单例类写出来

public class SingletonTest {
    //懒汉式单例类.在第一次调用的时候实例化自己 
    private SingletonTest() {}
        private static SingletonTest single=null;
        //静态工厂方法 
        public static SingletonTest getInstance() {
             if (single == null) {  
                 single = new SingletonTest();
                 System.out.println("创建一次");
             }  
            return single;
        }
        
        public void show(){
            System.out.println("我是show");
        }

}

这里直接上代码,代码中有详解

public class SingletonTest2 {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        //故意写获取两次,创建两个对象
        SingletonTest singleton=SingletonTest.getInstance();
        SingletonTest singleton2=SingletonTest.getInstance();
        
        //Singleton对象只创建一次,但是写两次还是可以的,而且方法都是可以调用的,但是看下面
        singleton.show();
        singleton2.show();
        
        //两个对象的表现形式一样
        if(singleton == singleton2){
            System.out.println("该对象的字符串表示形式:");
            System.out.println("singleton :"+singleton.toString());
            System.out.println("singleton2:"+singleton2.toString());
        }
}

输出结果如下: 

 

 这时候我们可以明显的看到singleton.ToString()方法输出了同一个值,证明singleton和singleton2是同一对象,因为SingletonTest.getInstance()方法只返回同一个实例对象。

但是由上面的图可以看出就算多创建几个对象,在底部也是只有一个singleton对象实例,而且创建出来的对象的字符串表现形式也是一样的,有的人肯定有疑问,那平常两个对象是什么样子的呢,我下面给你解释说明,在这之前我写说一下这个懒汉式需要注意的地方,它是线程不安全的,并发环境下很可能出现多个Singleton实例,有很多方法可以解决,比如说同步锁静态内部类

同步锁:双重效验锁(double checking lock)

public class SynchronizedSingleton {
 
    //一个静态的实例
    private static SynchronizedSingleton synchronizedSingleton;
    //私有化构造函数
    private SynchronizedSingleton(){}
    //给出一个公共的静态方法返回一个单一实例
    public static SynchronizedSingleton getInstance(){
        if (synchronizedSingleton == null) {
            synchronized (SynchronizedSingleton.class) {
                if (synchronizedSingleton == null) {
                    synchronizedSingleton = new SynchronizedSingleton();
                }
            }
        }
        return synchronizedSingleton;
    }
}

我们去掉同步块中的是否为null的判断,有这样一种情况,假设A线程和B线程都在同步块外面判断了synchronizedSingleton为null,结果A线程首先获得了线程锁,进入了同步块,然后A线程会创造一个实例,此时synchronizedSingleton已经被赋予了实例,A线程退出同步块,直接返回了第一个创造的实例,此时B线程获得线程锁,也进入同步块,此时A线程其实已经创造好了实例,B线程正常情况应该直接返回的,但是因为同步块里没有判断是否为null,直接就是一条创建实例的语句,所以B线程也会创造一个实例返回,此时就造成创造了多个实例的情况。

经过刚才的分析,貌似上述双重加锁的示例看起来是没有问题了,但如果再进一步深入考虑的话,其实仍然是有问题的。

如果我们深入到JVM中去探索上面这段代码,它就有可能(注意,只是有可能)是有问题的。

因为虚拟机在执行创建实例的这一步操作的时候,其实是分了好几步去进行的,也就是说创建一个新的对象并非是原子性操作。在有些JVM中上述做法是没有问题的,但是有些情况下是会造成莫名的错误。

首先要明白在JVM创建新的对象时,主要要经过三步。

              1.分配内存

              2.初始化构造器

              3.将对象指向分配的内存的地址

这种顺序在上述双重加锁的方式是没有问题的,因为这种情况下JVM是完成了整个对象的构造才将内存的地址交给了对象。但是如果2和3步骤是相反的(2和3可能是相反的是因为JVM会针对字节码进行调优,而其中的一项调优便是调整指令的执行顺序),就会出现问题了。

因为这时将会先将内存地址赋给对象,针对上述的双重加锁,就是说先将分配好的内存地址指给synchronizedSingleton,然后再进行初始化构造器,这时候后面的线程去请求getInstance方法时,会认为synchronizedSingleton对象已经实例化了,直接返回一个引用。如果在初始化构造器之前,这个线程使用了synchronizedSingleton,就会产生莫名的错误。

解决办法:

1.给静态的实例属性加上关键字volatile,标识这个属性是不需要优化的。

这样也不会出现实例化发生一半的情况,因为加入了volatile关键字,就等于禁止了JVM自动的指令重排序优化,并且强行保证线程中对变量所做的任何写入操作对其他线程都是即时可见的。这里没有篇幅去介绍volatile以及JVM中变量访问时所做的具体动作,总之volatile会强行将对该变量的所有读和取操作绑定成一个不可拆分的动作。如果读者有兴趣的话,可以自行去找一些资料看一下相关内容。

不过值得注意的是,volatile关键字是在JDK1.5以及1.5之后才被给予了意义,所以这种方式要在JDK1.5以及1.5之后才可以使用,但仍然还是不推荐这种方式,一是因为代码相对复杂,二是因为由于JDK版本的限制有时候会有诸多不便。

2.将该任务交给JVM,所以有一种比较标准的单例模式。如下所示。

静态内部类:

注:静态内部类虽然保证了单例在多线程并发下的线程安全性,但是在遇到序列化对象时,默认的方式运行得到的结果就是多例的。这种情况不多做说明了,使用时请注意。

public class InnerClassSingleton {
    
    public static Singleton getInstance(){
        return Singleton.singleton;
    }
 
    private static class Singleton{
        
        protected static Singleton singleton = new Singleton();
        
    }
}

这种方式为何会避免了上面莫名的错误,主要是因为一个类的静态属性只会在第一次加载类时初始化,这是JVM帮我们保证的,所以我们无需担心并发访问的问题。所以在初始化进行一半的时候,别的线程是无法使用的,因为JVM会帮我们强行同步这个过程。另外由于静态变量只初始化一次,所以singleton仍然是单例的。 

 上述形式保证了以下几点:

1.Singleton最多只有一个实例,在不考虑反射强行突破访问限制的情况下。

2.保证了并发访问的情况下,不会发生由于并发而产生多个实例。

3.保证了并发访问的情况下,不会由于初始化动作未完全完成而造成使用了尚未正确初始化的实例。


我们用另外一段代码来说明一下静态内部类实现单例:

public class SingletonDemo5 {
    private static class SingletonHolder{
        private static final SingletonDemo5 instance = new SingletonDemo5();
    }
    private SingletonDemo5(){}
    public static final SingletonDemo5 getInsatance(){
        return SingletonHolder.instance;
    }
}

 这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程,只要Singleton类被装载了,那么instance就会被实例化(没有达到lazy loading效果),而这种方式是Singleton类被装载了,instance不一定被初始化。因为SingletonHolder类没有被主动使用,只有显示通过调用getInstance方法时,才会显示装载SingletonHolder类,从而实例化instance。想象一下,如果实例化instance很消耗资源,我想让他延迟加载,另外一方面,我不希望在Singleton类加载时就实例化,因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载,那么这个时候实例化instance显然是不合适的。这个时候,这种方式相比第三和第四种方法就显得更合理。

2.饿汉式单例

public class Singleton1 {
  private Singleton1() {}
  private static final Singleton1 single = new Singleton1();
  //静态工厂方法 
  public static Singleton1 getInstance() {
      return single;
  }
}

因为这本身就是static修饰的方法,所以是在类加载的时候被创建,后期不会再改变,所以线程是安全的。

参考博文:

https://blog.csdn.net/qq_36470686/article/details/84981060

https://www.cnblogs.com/cmusketeer/p/8016550.html

https://www.cnblogs.com/CodeGuy/p/3580486.html

猜你喜欢

转载自blog.csdn.net/weixin_42504145/article/details/85006406