zoukankan      html  css  js  c++  java
  • Java 设计模式之单利模式

    一、首先介绍一下单例模式: 
        单例模式(Singleton),也叫单子模式,是一种常用的软件设计模式。在应用这个模式时,单例对象的类必须保证只有一个实例存在。许多时候整个系统只需要拥有一个的全局对象,这样有利于我们协调系统整体的行为。比如在某个服务器程序中,该服务器的配置信息存放在一个文件中,这些配置数据由一个单例对象统一读取,然后服务进程中的其他对象再通过这个单例对象获取这些配置信息。这种方式简化了在复杂环境下的配置管理。 

    实现单例模式的思路是: 
        一个类能返回对象一个引用(永远是同一个)和一个获得该实例的方法(必须是静态方法,通常使用getInstance这个名 称);当我们调用这个方法时,如果类持有的引用不为空就返回这个引用,如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用;同时我们 还将该类的构造函数定义为私有方法,这样其他处的代码就无法通过调用该类的构造函数来实例化该类的对象,只有通过该类提供的静态方法来得到该类的唯一实例。 

    需要注意的地方: 
        单例模式在多线程的 应用场合下必须小心使用。如果当唯一实例尚未创建时,有两个线程同时调用创建方法,那么它们同时没有检测到唯一实例的存在,从而同时各自创建了一个实例, 这样就有两个实例被构造出来,从而违反了单例模式中实例唯一的原则。 解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁(虽然这样会降低效率)。

    因程序需要,有时我们只需要某个类同时保留一个对象,不希望有更多对象,此时,我们则应考虑单例模式的设计。

    二. 单例模式的特点

    1. 单例模式只能有一个实例。

    2. 单例类必须创建自己的唯一实例。

    3. 单例类必须向其他对象提供这一实例。

    三. 单例模式VS静态类

    在知道了什么是单例模式后,我想你一定会想到静态类,“既然只使用一个对象,为何不干脆使用静态类?”,这里我会将单例模式和静态类进行一个比较。

    1. 单例可以继承和被继承,方法可以被override,而静态方法不可以。

    2. 静态方法中产生的对象会在执行后被释放,进而被GC清理,不会一直存在于内存中。

    3. 静态类会在第一次运行时初始化,单例模式可以有其他的选择,即可以延迟加载。

    4. 基于2, 3条,由于单例对象往往存在于DAO层(例如sessionFactory),如果反复的初始化和释放,则会占用很多资源,而使用单例模式将其常驻于内存可以更加节约资源。

    5. 静态方法有更高的访问效率。

    6. 单例模式很容易被测试。

    几个关于静态类的误解:

    误解一:静态方法常驻内存而实例方法不是。

    实际上,特殊编写的实例方法可以常驻内存,而静态方法需要不断初始化和释放。

    误解二:静态方法在堆(heap)上,实例方法在栈(stack)上。

    实际上,都是加载到特殊的不可写的代码内存区域中。

    静态类和单例模式情景的选择:

    情景一:不需要维持任何状态,仅仅用于全局访问,此时更适合使用静态类。

    情景二:需要维持一些特定的状态,此时更适合使用单例模式。

    四. 单例模式的优缺点

    优点: 
        1.在单例模式中,活动的单例只有一个实例,对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化,确保所有的对象都访问一个实例 
        2.单例模式具有一定的伸缩性,类自己来控制实例化进程,类就在改变实例化进程上有相应的伸缩性。 
        3.提供了对唯一实例的受控访问。 
        4.由于在系统内存中只存在一个对象,因此可以 节约系统资源,当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。 
        5.允许可变数目的实例。 
        6.避免对共享资源的多重占用。 
    缺点: 
        1.不适用于变化的对象,如果同一类型的对象总是要在不同的用例场景发生变化,单例就会引起数据的错误,不能保存彼此的状态。 
        2.由于单利模式中没有抽象层,因此单例类的扩展有很大的困难。 
        3.单例类的职责过重,在一定程度上违背了“单一职责原则”。 
        4.滥用单例将带来一些负面问题,如为了节省资源将数据库连接池对象设计为的单例类,可能会导致共享连接池对象的程序过多而出现连接池溢出;如果实例化的对象长时间不被利用,系统会认为是垃圾而被回收,这将导致对象状态的丢失。 
    使用注意事项: 
        1.使用时不能用反射模式创建单例,否则会实例化一个新的对象 
        2.使用懒单例模式时注意线程安全问题 
        3.饿单例模式和懒单例模式构造方法都是私有的,因而是不能被继承的,有些单例模式可以被继承(如登记式模式) 
    适用场景: 
        单例模式只允许创建一个对象,因此节省内存,加快对象访问速度,因此对象需要被公用的场合适合使用,如多个模块使用同一个数据源连接对象等等。如: 
        1.需要频繁实例化然后销毁的对象。 
        2.创建对象时耗时过多或者耗资源过多,但又经常用到的对象。 
        3.有状态的工具类对象。 
        4.频繁访问数据库或文件的对象。 
    以下都是单例模式的经典使用场景: 
        1.资源共享的情况下,避免由于资源操作时导致的性能或损耗等。如上述中的日志文件,应用配置。 
        2.控制资源的情况下,方便资源之间的互相通信。如线程池等。 
    应用场景举例: 
        1.外部资源:每台计算机有若干个打印机,但只能有一个PrinterSpooler,以避免两个打印作业同时输出到打印机。内部资源:大多数软件都有一个(或多个)属性文件存放系统配置,这样的系统应该有一个对象管理这些属性文件 
        2. Windows的Task Manager(任务管理器)就是很典型的单例模式(这个很熟悉吧),想想看,是不是呢,你能打开两个windows task manager吗? 不信你自己试试看哦~ 
        3. windows的Recycle Bin(回收站)也是典型的单例应用。在整个系统运行过程中,回收站一直维护着仅有的一个实例。 
        4. 网站的计数器,一般也是采用单例模式实现,否则难以同步。 
        5. 应用程序的日志应用,一般都何用单例模式实现,这一般是由于共享的日志文件一直处于打开状态,因为只能有一个实例去操作,否则内容不好追加。 
        6. Web应用的配置对象的读取,一般也应用单例模式,这个是由于配置文件是共享的资源。 
        7. 数据库连接池的设计一般也是采用单例模式,因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池,主要是节省打开或者关闭数据库连接所引起的效率损耗,这种效率上的损耗还是非常昂贵的,因为何用单例模式来维护,就可以大大降低这种损耗。 
        8. 多线程的线程池的设计一般也是采用单例模式,这是由于线程池要方便对池中的线程进行控制。 
        9. 操作系统的文件系统,也是大的单例模式实现的具体例子,一个操作系统只能有一个文件系统。 
        10. HttpApplication 也是单位例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式,所有的HttpModule都共享一个HttpApplication实例. 
       
    实现单利模式的原则和过程: 
        1.单例模式:确保一个类只有一个实例,自行实例化并向系统提供这个实例 
        2.单例模式分类:饿单例模式(类加载时实例化一个对象给自己的引用),懒单例模式(调用取得实例的方法如getInstance时才会实例化对象)(java中饿单例模式性能优于懒单例模式,c++中一般使用懒单例模式) 
        3.单例模式要素: 
            a.私有构造方法 
            b.私有静态引用指向自己实例 
            c.以自己实例为返回值的公有静态方法

     代码的实现:

    1. 懒汉模式

    /**
    * 类同步
    */
    public
    class SingletonDemo { private static SingletonDemo instance; private SingletonDemo(){ } public static SingletonDemo getInstance(){ if(instance==null){ instance=new SingletonDemo(); } return instance; } }

    /**
    * 方法同步
    */
    @Component
    public class LazySingleton {

    private static LazySingleton lazySingleton = null;

    public static LazySingleton getInstance(){
    if (lazySingleton == null){
    synchronized (LazySingleton.class){ // 获得对象锁,然后锁住这一段代码
    /**
    * 在synchronized中的if判断是为了防止多个线程凑巧同时第一次调用getInstance,
    * 它们都会去进入synchronized块中,因为new一个这玩意需要很多资源,所以让它们再排队后再判断一次。
    */
    if (lazySingleton == null){
    lazySingleton = new LazySingleton();
    }
    }
    }
    return lazySingleton;
    }

    private LazySingleton(){
    System.out.println("================================ 懒汉单利模式");
    }

    }
     

    如上,通过提供一个静态的对象instance,利用private权限的构造方法和getInstance()方法来给予访问者一个单例。

    缺点是,没有考虑到线程安全,可能存在多个访问者同时访问,并同时构造了多个对象的问题。之所以叫做懒汉模式,主要是因为此种方法可以非常明显的lazy loading。

    针对懒汉模式线程不安全的问题,我们自然想到了,在getInstance()方法前加锁,于是就有了第二种实现。

    2.线程安全的懒汉模式

    public class SingletonDemo {
        private static SingletonDemo instance;
        private SingletonDemo(){
    
        }
        public static synchronized SingletonDemo getInstance(){
            if(instance==null){
                instance=new SingletonDemo();
            }
            return instance;
        }
    }

    然而并发其实是一种特殊情况,大多时候这个锁占用的额外资源都浪费了,这种打补丁方式写出来的结构效率很低。

    3. 饿汉模式

    /**
     *  饿汉式单例模式
     * Created by Ulegal on 2017/11/29.
     */
    @Component
    public class Singleton {
    
        /**
         *  设立静态变量,直接创建实例
         */
        private static final Singleton ourInstance = new Singleton();
    
        /**
         *  开放一个公有方法,判断是否已经存在实例,有返回,没有新建一个在返回
         * @return
         */
         public static Singleton getInstance() {
             System.out.println("-->饿汉式单例模式开始调用公有方法返回实例");
             return ourInstance;
        }
    
        /**
         *  私有化构造函数
         */
        private Singleton() {
            //私有化构造函数
            System.out.println("-->饿汉式单例模式开始调用构造函数");
    
        }

    直接在运行这个类的时候进行一次loading,之后直接访问。显然,这种方法没有起到lazy loading的效果,考虑到前面提到的和静态类的对比,这种方法只比静态类多了一个内存常驻而已。

    4.静态类内部加载

    public class SingletonDemo {
        private static class SingletonHolder{
            private static SingletonDemo instance=new SingletonDemo();
        }
        private SingletonDemo(){
            System.out.println("Singleton has loaded");
        }
        public static SingletonDemo getInstance(){
            return SingletonHolder.instance;
        }
    }

    使用内部类的好处是,静态内部类不会在单例加载时就加载,而是在调用getInstance()方法时才进行加载,达到了类似懒汉模式的效果,而这种方法又是线程安全的。

    5.枚举方法

    enum SingletonDemo{
        INSTANCE;
        public void otherMethods(){
            System.out.println("Something");
        }
    }

    Effective Java作者Josh Bloch 提倡的方式,在我看来简直是来自神的写法。解决了以下三个问题:

    (1)自由序列化。

    (2)保证只有一个实例。

    (3)线程安全。

    如果我们想调用它的方法时,仅需要以下操作:

    public class Hello {
        public static void main(String[] args){
            SingletonDemo.INSTANCE.otherMethods();
        }
    }

    这种充满美感的代码真的已经终结了其他一切实现方法了。

    6. 双重校验锁法

    public class SingletonDemo {
        private volatile static SingletonDemo instance;
        private SingletonDemo(){
            System.out.println("Singleton has loaded");
        }
        public static SingletonDemo getInstance(){
            if(instance==null){
                synchronized (SingletonDemo.class){
                    if(instance==null){
                        instance=new SingletonDemo();
                    }
                }
            }
            return instance;
        }
    }

    接下来我解释一下在并发时,双重校验锁法会有怎样的情景:

    STEP 1. 线程A访问getInstance()方法,因为单例还没有实例化,所以进入了锁定块。

    STEP 2. 线程B访问getInstance()方法,因为单例还没有实例化,得以访问接下来代码块,而接下来代码块已经被线程1锁定。

    STEP 3. 线程A进入下一判断,因为单例还没有实例化,所以进行单例实例化,成功实例化后退出代码块,解除锁定。

    STEP 4. 线程B进入接下来代码块,锁定线程,进入下一判断,因为已经实例化,退出代码块,解除锁定。

    STEP 5. 线程A获取到了单例实例并返回,线程B没有获取到单例并返回Null。

    理论上双重校验锁法是线程安全的,并且,这种方法实现了lazyloading。

    饿汉模式源码 : https://gitee.com/xdymemory00/DanLiMoShi.git

  • 相关阅读:
    python中int类型、bool类型补充,及字符串的部分常用方法
    while循环、流程控制、基本运算符、编码问题、in和not in
    python的起源、解释器、变量用户交互、流程控制
    Spring-Security (学习记录三)--读取数据库中的用户和角色
    Spring-Security (学习记录二)--修改为自己的登录页面
    java中get请求的中文乱码问题
    python打开文件的方式
    js闭包
    Java内部类的整理。
    HTML+CSS标签的属性及应用
  • 原文地址:https://www.cnblogs.com/memoryXudy/p/7929845.html
Copyright © 2011-2022 走看看