java设计模式---你所不知道的单例模式

单例模式大家都听说过,而且也是项目中最常出现的,但是,我们该如何的去更好的使用单例,如何去保证创建的时候线程安全,如何使得DCL模式不失效问题,如何去避免不必要的资源消耗问题,看到这些前奏,想必大家都会有种往下看的冲动了吧,来看看实现单例的几个关键点:

  • 构造函数不能对外开放
  • 通过一个静态方法或枚举返回单例类对象
  • 确保单例类的对象有且只有一个,尤其是在多线程环境下
  • 确保单例类对象在反序列化时不会重新构建对象

单例模式的种类:

  1. 饿汉式
  2. 懒汉式

饿汉式

首先来看看饿汉式的代码模板

public class Test {

    public static void main(String[] args) {
         System.out.println(App.getInstance());
         System.out.println(App.getInstance());
    }
}

class App {

    private static final App app = new App();

    private App() {

    }
    public static App getInstance() {
        return app;
    }
}

饿汉式的特点很明显,先初始化类对象,然后通过暴露出的方法返回对象,构造函数设置为private,保证了实例的唯一性,但是吧,我觉得这种方式每次都要去初始化这个类对象,有时候我不需要去获取实例,仅仅只是需要里面的一个方法,这就会有点小小的浪费资源,如何在调用实例化方法的时候再去创建实例呢?那就是用懒汉式的方式去实现了


饿汉式:

要讲的那就多了,而且实现方式也有很多,来看看平时小白用的最多的方式

public class Test {

    public static void main(String[] args) {
        System.out.println(App.getInstance());
        System.out.println(App.getInstance());
    }
}

class App {

    private static App app = null;

    private App() {

    }

    public static App getInstance() {
        if (app == null)
            app = new App();
        return app;
    }
}

这种方式确实能实现实例的唯一化,但是如果存在很多个线程去访问该类,并去创建实例的时候,你会发现,创建的实例对象打印出来会偶然发现有些实例对象不一样,保证不了线程的安全性还有实例的唯一性,如何让很多个进来的线程进行排队,我先进,你们后面的等等,我出来后你们再进,这样我进来后,对象已经实例化了,不再等于null,即使你们进来了,也不会造成实例再次被初始化,这下,我们要引出同步方法去维护实例的唯一性,上代码:

public class Test {

    public static void main(String[] args) {
        System.out.println(App.getInstance());
        System.out.println(App.getInstance());
    }
}

class App {

    private static App app = null;

    private App() {

    }

    public static synchronized App getInstance() {
        if (app == null)
            app = new App();
        return app;
    }
}

在实例化方法前面加个synchronized,保证线程的同步,这种方式的话,你多个线程进来,我也不怕会被创建多个实例出来,确保了唯一性,但是,这种方式又存在了一个小缺点,那就是,每次创建或者去访问实例的时候,都要去触发这个同步的方法,同步方法是很消耗资源的,有没有更好的办法在我创建的时候去同步,下次去拿实例的时候就不走同步方法,而是直接给我实例对象值呢,接下来就要引出单例的另一种实现模式—-DCL模式(Double CheckLock),上代码

public class Test {

    public static void main(String[] args) {
        System.out.println(App.getInstance());
        System.out.println(App.getInstance());
    }
}

class App {

    private static App app = null;

    private App() {

    }

    public static App getInstance() {
        if (app == null) {
            synchronized (App.class) {
                if (app == null)
                    app = new App();
            }
        }
        return app;
    }
}

哈哈,这种方式再也不担心所有的情况发生了,每次为null的时候我再去使用同步方法去创建实例,以后再调用该实例方法获取实例的时候,就再也不需要去走同步方法了,即能解决线程的安全性也能解决同步资源消耗问题,是不是心里觉得美滋滋的呢,但是,我又要说这种方式的不是太好,你会不会又要揍我呢,好怕怕哦,那我赶紧把问题说出来



在执行app = new App();的时候,他并不是一个原子操作,这句代码最终会被编译成许多的汇编指令,大致做了这几件事:

  1. 给App的实例分配内存
  2. 调用App的构造函数,初始化成员字段
  3. 将app对象指向分配的内存空间(此时app就不是null了)

由于java编译器允许处理器乱序执行,以及jdk1.5之前JMM(java模型)中的Cache、寄存器到主内存回写顺序的规定,上面2和3的顺序是无法保证的,有可能执行顺序是123,也有可能是132,如果执行顺序是123的话那没问题,假如是132的情况话,那就来分析分析这种情况为啥出错,有个A线程进来,先执行了步骤3,那我这个实例就被指向了分配的内存空间,然后线程B进来了,发现app已经被指向分配过了,所以不是null,直接返回了实例,并没有去执行步骤2的构造函数来初始化实例,也就是没有给他一块内存区域来存放实例,那拿到的这个实例其实是错误的,只是获取到的是被指向的内存,并没有真正的被创建,所以引用的时候就会发生错误,这也就是DCL失效问题,那如何去解决这个问题呢?
当然是有办法的啦,我们只需要在private static App app = null;里面加个关键字volatile,如下:

public class Test {

    public static void main(String[] args) {
        System.out.println(App.getInstance());
        System.out.println(App.getInstance());
    }
}

class App {

   //volatile
    private volatile static App app = null;

    private App() {

    }

    public static App getInstance() {
        if (app == null) {
            synchronized (App.class) {
                if (app == null)
                    app = new App();
            }
        }
        return app;
    }
}

这样就解决了DCL失效的问题了,当然,volatile或多或少也会影响到性能问题,但是考虑到程序的正确性,牺牲这点性能还是值得的。


DCL模式的特点:

资源利用高,第一次执行getInstance时单例对象才会被实例化,效率高

DCL模式的缺点:

第一次加载时反应慢,也由于java内存模型的原因偶尔会失败。在高并发环境下也有一点的缺陷,虽然发生概率小,

DCL模式是使用最多的单例模式,虽然有点缺陷,但是在jdk1.6之前sun公司就调整了JMM,具体化了volatile关键字,所以,在jdk1.6之后,高并发的场景基本上是能满足需求的。



DCL虽然在一定程度上解决了资源消耗、内存同步、线程安全等问题,但是还是有问题,有大神提出不赞成使用,他的代码如下

public class Test {

    public static void main(String[] args) {
          System.out.println(App.getInstance());
          System.out.println(App.getInstance());
    }
}

class App {
    private App() {
    }

    public static App getInstance() {
        return singleHolder.app;
    }

    private static class singleHolder {
        private static final App app = new App();
    }
}

当第一次加载App类并不会初始化app,只有在第一次调用App的getInstance方法才会导致app的被初始化,因此,第一次调用getInstance方法会导致虚拟机加载singleHolder类,这种方式不仅能够确保线程安全,也能够保证单例对象的唯一性,同时也延缓了单例的实例化,所以这是推荐使用的单例模式实现方式。



既然是做android开发的,当然也讲讲安卓中的单例例子

用容器来实现单例模式

最常见的当然是android中的应用退出,看看代码

public class Activity {

    public void onCreateView() {
        ActivityManager.put(this);
        //dosomething
    }
}

class ActivityManager {
    private static List<Activity> list = new ArrayList<Activity>();

    public static void put(Activity activity) {
        if (!list.contains(activity)) {
            list.add(activity);
        }
    }

    public static Activity get(Activity activity) {
        int position;
        if ((position = list.indexOf(activity)) >= 0) {
            return list.get(position);
        } else {
            return null;
        }
    }

    public static void finish() {
        for (Activity activity : list) {
            activity.finish();
        }
    }
}

将自己当前的实例交给ActivityManager去管理,每次想去要实例的时候,就去集合里面拿,避免了多次实例创建,在安卓应用中,退出应用的时候,直接finish掉所有的实例,最常见的当然属应用的退出登陆,退出的时候需要把所有的Activity关闭掉,然后打开登陆界面,这时候,就可以调用ActivityManager的finish方法,然后Intent打开登陆的Activity,这样就完美的解决了



其实还有很多的单例方式,上面的例子还是没有解决反序列化问题,也就是将单例的实例写到磁盘上面去,然后去读取磁盘返回来的实例,没做好反序列化的时候,读取磁盘返回的实例不是之前的实例,而是另外一个实例了,不过,在自己做应用的时候,是可以避免的,最后还有一个enum枚举单例,他不会出现以上的所有问题,而且还不会被反序列化造成单例不一致。

好了,差不多了,在学习的路上推荐大家看《android源码设计模式》这本书,讲的很不错,是进阶中的一本好书

时间: 2024-11-06 09:33:30

java设计模式---你所不知道的单例模式的相关文章

【干货合集】你所不知道的蚂蚁技术系列之(一):系统设计、性能优化、运维

8月30-31日20:00-21:30,一场别开生面的技术大会-- "蚂蚁金服&阿里云在线金融技术峰会"将在线举办.本次将聚焦数据库.应用架构.移动开发.机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践. 蚂蚁金服&阿里云在线金融技术峰会专题:https://yq.aliyun.com/activity/109 峰会统一报名链接:http://yq.aliyun.com/webinar/join/38 2015双11,蚂蚁金服旗下支付宝共完

【javascript杂谈】你所不知道的replace函数

原文:[javascript杂谈]你所不知道的replace函数 前言 最近在做面试题的时候总会用到这个函数,这个函数总是和正则表达式联系到一起,并且效果很是不错,总能很简单出色的完成字符串的实际问题,大家肯定都会使用这个函数,像我一样的初学者可能对这个函数的了解还是不够深的,今天就总结一下,了解一下,再做几道网上的题目练练手,给将要面试的同学打打气. 介绍 使用一个替换值替换掉一个替换模式在原字符串中一个或所有的匹配项,并返回替换后的字符串,这个替换模式可以是字符串或者正则表达式,替换值可以是

你所不知道的关于网管的危险做法

  你所不知道的关于网管的危险做法 网络管理员是指向社会公众开放的营业性上网服务提供场所里的管理员.Jeff Dray 最近经过对IT行业的深入调查研究,通过总结和分析针对IT行业列出了一份类别名单.在这里,他定义了七类最不安全的网络管理员.如果你是一名网络管理员,并且已经意识到工作中还存在着不足,看看你属于名单中的哪一类? 大多数网络管理员对工作游刃有余,并且可以在一个具有高度挑战和技术难度的任务中,使工作顺利进行.然而,有时他们中的某些人会变得很难缠,并会阻碍事情的顺利进行.所以,我定义了一

【干货合集】你所不知道的蚂蚁技术系列之(二):数据、Docker、测试与无线网络技术

8月30-31日20:00-21:30,一场别开生面的技术大会-- "蚂蚁金服&阿里云在线金融技术峰会"将在线举办.本次将聚焦数据库.应用架构.移动开发.机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践. 蚂蚁金服&阿里云在线金融技术峰会专题:https://yq.aliyun.com/activity/109 峰会统一报名链接:http://yq.aliyun.com/webinar/join/38 2015双11,蚂蚁金服旗下支付宝共完

【干货合集】你所不知道的蚂蚁技术系列之(三):咻红包、人脸识别、人工智能、金融技术

8月30-31日20:00-21:30,一场别开生面的技术大会-- "蚂蚁金服&阿里云在线金融技术峰会"将在线举办.本次将聚焦数据库.应用架构.移动开发.机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践. 蚂蚁金服&阿里云在线金融技术峰会专题:https://yq.aliyun.com/activity/109 峰会统一报名链接:http://yq.aliyun.com/webinar/join/38 2015双11,蚂蚁金服旗下支付宝共完

你所不知道的CSS滤镜技巧与细节

本文主要介绍 CSS 滤镜的不常用用法,希望能给读者带来一些干货! OK,下面直接进入正文.本文所描述的滤镜,指的是 CSS3 出来后的滤镜,不是 IE 系列时代的滤镜,语法如下,还未接触过这个属性的可以先简单到 MDN - filter 了解下: {      filter: blur(5px);      filter: brightness(0.4);      filter: contrast(200%);      filter: drop-shadow(16px 16px 20px 

QML中你所不知道的state

QML中你所不知道的state        最后一次写QML已经是2010年了,最近由于产品需要,重拾QML.之前nokia给我们培训QML的时候,对于state这个概念理解的不是很透彻.最近在做产品前期的QML热身,发现QML中的state有一种神奇的功能:历史记忆效应        state核心就是体现了一个状态机的原理,处在某一状态去改变某些属性以达到目的.关于state如何使用的我这里就不说了,看看nokia的QML文档就知道state如何使用.我这里主要讲讲state的历史记忆效应

你所不知道的SQL Server数据库启动过程,以及启动不起来的各种问题的分析及解决技巧

原文:你所不知道的SQL Server数据库启动过程,以及启动不起来的各种问题的分析及解决技巧 目前SQL Server数据库作为微软一款优秀的RDBMS,其本身启动的时候是很少出问题的,我们在平时用的时候,很少关注起启动过程,或者很少了解其底层运行过程,大部分的过程只关注其内部的表.存储过程.视图.函数等一系列应用方式,而当有一天它运行的正常的时候突然启动不起来了,这时候就束手无策了,能做的或许只能是重装.配置.还原等,但这一个过程其实是一个非常耗时的过程,尤其当我们面对是庞大的生产库的时候,

zz疯转:云计算,你所不知道的真相

问题描述 疯转:云计算,你所不知道的真相作者:打死我也得说云计算已经成为不可逆转的产业趋势,云计算概念的火热,不仅让IT人员言必称精通云计算的专家,很多企业的董事长.总经理都亲自过问公司的信息化建设,推动公司转型成云计算的云公司.可是,关于云计算的真相,你真的知道多少?快快了解以下真相,让你成为小伙伴心目中真正的云计算专家吧!否则,千万别给别人说你懂,不然装B代价惨重,nozuonodie啊!(1)云服务商动辄号称99.9%以上的可用性,其实理论上都难以达到国内外云服务提供商几乎都号称自己能提供