java设计模式(一)单例模式

开篇废话

在写这篇博客之前,我一直以为单例模式是最简单的设计模式,哼,我还是太天真了。总结一下学习收获吧。

什么是单例模式

单例模式的设计,保证了类的实例在系统运行的过程中,有且只有一个实例。说白了就是整个系统中,只new了一次。在不同的地方去使用类的时候,使用的都是同一个类的实例。

常用的单例模式分这么几类:

  • 懒汉式:我也不知道为什么起名懒汉式,分为线程安全和非线程安全。
  • 饿汉式:可能是设计者当时肚子饿吧。
  • 静态内部类:解释如名。
  • 枚举类:一个听说很高级的用法。

单例模式的优点:

在Java应用中,单例对象能保证在一个JVM中,该对象只有一个实例存在。这样的模式有几个好处:(此处抄袭)

  • 在内存中只有一个对象,节省内存空间。
  • 避免频繁的创建销毁对象,可以提高性能。
  • 避免对共享资源的多重占用。
  • 可以全局访问

单例模式应用场景:

  • 需要频繁实例化然后销毁的对象。
  • 创建对象时耗时过多或者耗资源过多,但又经常用到的对象。
  • 有状态的工具类对象。
  • 频繁访问数据库或文件的对象。
  • 管理类对象,例如Android系统中的的各个ServiceManager。
  • 一些在系统只能存在一个实例的情况。

懒汉式单例模式(线程不安全)

public class Student {
    private static Student instance = null;

    private Student() {

    }

    public static Student getInstance() {
        if (null == instance) {
            instance = new Student();
        }
        return instance;
    }
}

这应该是我们最常见而且最常用的单例模式的写法了,在我写这篇博客之前我一直以为这就是所有的单例模式了。实则不然,因为它忽略了多线程的问题,因为如果在同一时刻,两个线程同时调用getInstance()来获取实例,此时两者都判断为null,于是系统中就会存在两个实例了,违背了单例模式的特性。

懒汉式单例模式(线程安全)

public class Student {
    private static Student instance = null;

    private Student() {

    }

    public static synchronized Student getInstance() {
        if (null == instance) {
            instance = new Student();
        }
        return instance;
    }
}

可以看到,我们在getInstance()方法前加入了synchronized关键字,这是用于同步的关键字,加入这个关键字之后,getInstance()就会获得一个同步锁,假如现在有两个人线程A,B都要去调用getInstance()方法,若A此时调用getInstance(),jvm会对getInstance()上锁,就是告诉其他线程,现在这个方法有人用了,线程B要用的话,必须等A执行结束后,才会释放锁,这时候B才能调用。这样就杜绝了线程同步的问题。
但是,这样有个问题就是效率的问题,就是会强制除A之外的所有线程等待,这样会造成资源效率的影响。
于是大家又对其进行优化:

Double-Check双重检验锁

public class Student {
    private volatile static Student instance = null;

    private Student() {

    }

    public static Student getInstance() {
        // 先检查一遍是否存在单例对象
        if (null == instance) {
            //如果存在就直接返回,不需要上锁,如果不存在,再进行同步操作
            synchronized (Student.class) {
                //安全起见,再次进行单例检查。
                if (null == instance) {
                    instance = new Student();
                }
            }
        }
        return instance;
    }
}

双重检验锁,在一定程度上提高了效率,是因为同步操作之前先进行了一次预处理,如果存在单例对象,直接返回就ok了,不需要进行同步操作了,没有优化前,是只要调用就需要同步,就意味着有其他线程要等待,优化之后,减小了等待的概率,从而在一定程度上会提高效率。

值得一提的是:

在双重检验锁的方法中,对instance对象的定义时,使用了volatile关键字。
volatile :被volatile修饰的变量的值,将不会被本地线程缓存,所有对该变量的读写都是直接操作共享内存,从而确保多个线程能正确的处理该变量。
使用volatile关键字JVM不会对其进行相关优化,所以运行效率并不是很高。因此一般建议,没有特别的需要,不要使用。也就是说,虽然可以使用”双重检查加锁“机制来实现线程安全的单例,但并不建议大量采用,可以根据情况来选用。

饿汉式单例模式

public class Student {
    private static Student instance = new Student() ;
    private Student() {

    }
    public static Student getInstance() {
        return instance;
    }
}

饿汉式单例模式,说白了就是在单例变量定义时就进行初始化,由于类装载的过程是由类加载器(ClassLoader)来执行的,这个过程也是由JVM来保证同步的,所以这种方式先天就有一个优势——能够免疫许多由多线程引起的问题。但是影响类装载的因素有很多,所以饿汉式在一定程度上也并不是绝对的线程安全。这里我也不是很懂,希望有了解的朋友能指点迷津。

静态内部类

public class Student {    
    private static class InstanceHolder {    
       private static final Student INSTANCE = new Student();    
    }
    
    private Student (){}   
    
    public static final Student getInstance() {    
       return InstanceHolder.INSTANCE;    
    }    
}

在类加载的时候,JVM会保证线程同步,我们可以看到INSTANCE是在InstanceHolder类中初始化的,而INSTANCE对象是InstanceHolder类的静态常量,也就是说在加载InstanceHolder类的时候,就会加载INSTANCE对象,利用JVM自动保证线程安全和唯一性。这种实现其实和饿汉式原理上是相通的,静态内部类的方式能够更加灵活的决定类加载的时间,这里是利用了内部类的加载机制, 内部类是延时加载的,也就是说只会在第一次使用时加载。不使用就不加载。

在这里,一开始我有个疑问,既然都是要加载,都必不可少的要消耗这部分的资源,那用静态内部类是不是显得有点鸡肋。但是仔细一想,并非如此,如果我们一直没有调用到getInstance()方法,这样系统就会少一笔加载的开销。但是如果这个方法定义了但是没有用,岂不是傻B?但是仔细想想,或许程序的艺术就在这里。我想我只能这样慰藉自己了,如果有不同观点朋友,还希望能不吝赐教!

枚举

/**
 * 
 * @author nothing of IT
 * 这里大家需要知道一个基础的概念:
 * 枚举是支持成员变量和成员方法的
 */
public enum People {
    //可以理解成静态实例
    INSTANCE;
    
    private int mAge;
    
    public int getAge() {
        return mAge;
    }
}

利用枚举的特性来实现单例模式,在使用时,直接通过People.INSTANCE来获取实例,通过People.INSTANCE.getAge()来调用实例的方法。如果PeoPle需要有参构造,代码是可以这样写的:

public enum People {
    INSTANCE(10);
    
    private int mAge;
    
    private People(int age) {
        mAge = age;
    }
    
    public int getAge() {
        return mAge;
    }
}

使用:People.INSTANCE(10),People.INSTANCE(10).getAge()。
但是说句实话,并没有太大的意义,因为参数在枚举时就必须传入,根本起不到参数的存在价值,所以说,枚举虽然使用方便,但是局限性也很多。

总结

在所有的设计模式中,单例模式可能是使用最广泛,相对来说较为简单的一种设计模式了。但是上述所有的类型中,饿汉式,静态内部类,枚举这三种本质上是一样,但是都存在一个局限就是,构造函数必须无参。
懒汉式的几种实现中,考虑的问题就是线程安全的问题,但是没有十全十美的方案,因为要保证线程安全就要损失效率,需要效率就会涉及线程安全。具体的使用还得看具体的情况了。

注意!!

以上所有的方案中,都是不支持继承的,因为他们的构造函数都是private的。

使得一个类不可被继承有两种方法,一个是final修饰,另外一种就是构造函数私有化!

image.png

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,937评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,503评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,712评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,668评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,677评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,601评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,975评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,637评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,881评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,387评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,971评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2 342

推荐阅读更多精彩内容