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

来源：互联网发布：网络文明调查结果编辑：程序博客网时间：2024/04/29 17:59

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

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

单例模式的种类：

饿汉式
懒汉式

饿汉式

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

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();的时候，他并不是一个原子操作，这句代码最终会被编译成许多的汇编指令，大致做了这几件事：

给App的实例分配内存
调用App的构造函数，初始化成员字段
将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源码设计模式》这本书，讲的很不错，是进阶中的一本好书

0 0