设计模式（三）—— 让我们一起来扒光“单例模式”

前言

时隔一月之久，设计模式第三篇终于来了。（好吧，主要还是我自己拖沓了，下次注意）

通过前两篇文章，相信大家已经对设计模式有了大概的了解。那么今天我们就正式进入模式的学习。首先肯定要先拿软柿子捏，单例模式——最简单的设计模式。

身为程序员，你可能没有系统的学习过设计模式，但是你一定知道单例模式，因为它相对简单，而且最常被大家所用到。既然大家都用到过，也都知道为什么我还要单独列出一篇文章来写呢？
​
因为绝大部分开发者平时对单例模式的认识，可能仅仅停留在“会用”的阶段。为什么会有这个模式？为什么要用这个模式？在哪里用单例模式最合适？乱用了会有什么负面影响？
​
这些可能大多数人都一知半解。今天就让我们大家一起来扒光单例模式的外衣，有深度的认识一下单例模式。

扒光

通过这篇文章你能学到什么

（建议你可以带着问题去学习）

  1. 单例模式的​定义
  2. 单例模式在Android源码中的应用
  3. 单例模式的九种写法以及优劣对比
  4. 单例模式的使用场景
  5. 单例模式存在的缺点​​​​​​

接下来我们就一起进入今天的学习了

单例模式的定义

在学单例模式之前，我想大家都会自己问自己：“单例模式存在的意义是什么？我们为什么要用单例模式？”

众所周知，在古代封建社会，一个国家都只有一个国王或者叫皇帝。我们在这个国家的任何一个地方，只要提起国王，大家都知道他是谁。因为国王是唯一的。其实这个就是单例模式的核心思想：保证对象的唯一性。

​单例模式(Singleton Pattern)：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。 单例模式是一种对象创建型模式。

​​从其定义我们可以看出来单例模式存在三个要点：

1、实例唯一性
2、自行创建
3、全局访问

​​​​如何设计一个优秀的单例模式​其实也是围绕着这三点来的。
​
说了这么多了，还不知道单例模式到底啥样呢？接下来我们一起来着手设计这个“国王”的单例类。我们先看一下单例模式的类图：

​
单例模式类图

单例模式的类图看起来很简单，一个私有的当前类型的成员变量，一个私有的构造方法，一个 getInstance 方法，创建对象不再通过new 而通过 getInstance 让该类自行创建。相信我们大多数人使用的单例模式都是这种，因为太简单了。但是单例模式的写法可不止这一种。接下来我们一起来看一下单例模式的九种写法。

单例模式的九种写法

一、饿汉式（静态常量）
 /**
 * 饿汉式（静态常量）
 */
class King {
    private static final King kingInstance = new King();

    static King getInstance() {
        return kingInstance;
    }

    private King() {
    }
}
  • 优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
  • 缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。
二、饿汉式（静态代码块）
/**
 * 饿汉式（静态代码块）
 */
class King {
    private static King kingInstance;

    static {
        kingInstance = new King();
    }

    private King() {
    }

    public static King getKingInstance() {
        return kingInstance;
    }
}
  • 优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
  • 缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。
三、懒汉式（线程不安全）
/**
 * 懒汉式（线程不安全）
 */
public class King {
    private static King kingInstance;

    private King() {
    }

    public static King getKingInstance() {
        if (kingInstance == null) {
            kingInstance = new King();
        }
        return kingInstance;
    }
}
  • 优点：懒加载，只有使用的时候才会加载。
  • 缺点：但是只能在单线程下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。
四、懒汉式（线程安全）
/**
 * 懒汉式（线程安全，同步方法）
 */
public class King {
    private static King kingInstance;

    private King() {
    }

    public static synchronized King getKingInstance() {
        if (kingInstance == null) {
            kingInstance = new King();
        }
        return kingInstance;
    }
}
  • 优点：懒加载，只有使用的时候才会加载，获取单例方法加了同步锁，保障线程安全。
  • 缺点：效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。
五、懒汉式（线程安全，同步代码块）
/**
 * 懒汉式（线程安全，同步代码块）
 */
public class King {
    private static King kingInstance;

    private King() {
    }

    public static King getKingInstance() {
        if (kingInstance == null) {
            synchronized (King.class) {
                kingInstance = new King();
            }
        }
        return kingInstance;
    }
}
  • 优点：改进了第四种效率低的问题。
  • 缺点：不能完全保证单例，假如一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。
六、双重检查（DCL）
/**
 * 双重检查（DCL）
 */
public class King {

    private static volatile King kingInstance;

    private King() {
    }

    public static King getKingInstance() {
        if (kingInstance == null) {
            synchronized (King.class) {
                if (kingInstance == null){
                    kingInstance = new King();
                }
            }
        }
        return kingInstance;
    }
}
  • 优点：线程安全；延迟加载；效率较高。
  • 缺点：JDK < 1.5 的时候不可用
  • 不可用原因：由于volatile关键字会屏蔽Java虚拟机所做的一些代码优化，可能会导致系统运行效率降低，而JDK 1.5 以及之后的版本都修复了这个问题。（面试装逼用，谨记！！！）
就是为了装逼
七、静态内部类
/**
 * 静态内部类
 */
public class King {

    private King() {
    }

    private static class KingInstance{
        private static final King KINGINSTANCE = new King();
    }

    public static King getInstance(){
        return KingInstance.KINGINSTANCE;
    }
}
  • 优点：避免了线程不安全，延迟加载，效率高。
  • 缺点：暂无，最推荐使用。
  • 特点：这种方式跟饿汉式方式采用的机制类似，但又有不同。
  • 两者都是采用了类装载的机制来保证初始化实例时只有一个线程。不同的地方在饿汉式方式是只要Singleton类被装载就会实例化，没有Lazy-Loading的作用，而静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
八、枚举
/**
 * 枚举
 */
public enum  King {
    KINGINSTANCE;
}
  • 优点：不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。
  • 缺点：JDK 1.5之后才能使用。
九、容器类管理
/**
 * 使用容器实现单例模式（可以用于管理单例，有兴趣的可以尝试一下）
 * */
class InstanceManager {
    private static Map<String, Object> objectMap = new HashMap<>();
    private InstanceManager(){}
    public static void registerService(String key,Object instance){
        if (!objectMap.containsKey(key)){
            objectMap.put(key,instance);
        }
    }
    public static Object getService(String key){
        return objectMap.get(key);
    }
}

/**
* 使用方式
* Dog类就不贴出来了 
* 自己随便写个就行
* 可以运行一下看看 打印的地址是否一致
*/
class Test {
    public static void main(String[] args) {

        InstanceManager .registerService("dog", new Dog());

        Dog dog = (Dog) InstanceManager .getService("dog");
        Dog dog2 = (Dog) InstanceManager .getService("dog");
        Dog dog3 = (Dog) InstanceManager .getService("dog");
        Dog dog4 = (Dog) InstanceManager .getService("dog");

        System.out.println(dog);
        System.out.println(dog2);
        System.out.println(dog3);
        System.out.println(dog4);
    }
}
  • 优点：在程序的初始，将多种单例类型注入到一个统一的管理类中，在使用时根据key获取对象对应类型的对象。这种方式使得我们可以管理多种类型的单例，并且在使用时可以通过统一的接口进行获取操作， 降低了用户的使用成本，也对用户隐藏了具体实现，降低了耦合度。
  • 缺点：不常用，有些麻烦

九种写法的优劣对比

名称 优点 缺点 是否推荐
饿汉式（静态常量） 写法简单，类装载时完成实例化。 避免了线程同步 急切实例化， 容易内存泄漏 可用
饿汉式（静态代码块） 同上 同上 可用
懒汉式（线程不安全） 懒加载 只能在单线程下使用 多线程不可用
懒汉式（线程安全，同步方法） 懒加载，方法同步锁 效率低 不推荐用
懒汉式（线程安全，同步代码块） 同上，同时改变效率低问题 不能完全保证单例 不推荐用
双重检查（DCL）① 线程安全；延迟加载；效率较高 JDK < 1.5 的时候不可用 JDK >1.5 推荐用
静态内部类② 线程安全，延迟加载，效率高。 暂无发现 墙裂推荐
枚举 写法简单，防止反序列化 JDK 1.5之后才能使用 JDK >1.5 推荐用
容器实现 可用管理多个单例对象 不常用，多创建了一个Map 可用

①：不可用原因：由于volatile关键字会屏蔽Java虚拟机所做的一些代码优化，可能会导致系统运行效率降低，而JDK 1.5 以及之后的版本都修复了这个问题。（面试装逼用，谨记！！！）

②：这种方式跟饿汉式方式采用的机制类似，但又有不同。两者都是采用了类装载的机制来保证初始化实例时只有一个线程。不同的地方在饿汉式方式是只要Singleton类被装载就会实例化，没有Lazy-Loading的作用， 而静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。

单例模式在Android源码中的应用

在我们每天接触的Android源码中其实也有很多地方用到了单例模式：

1、EventBus中获取实例：

private static volatile EventBus defaultInstance;
public static EventBus getDefault() {
    if (defaultInstance == null) {
        synchronized (EventBus.class) {
            if (defaultInstance == null) {
                defaultInstance = new EventBus();
            }
        }
    }
    return defaultInstance;
}

可以看到，EventBus采用的是双重检查（DCL）的方式实现的单例模式。

2、InputMethodManager获取实例

static InputMethodManager sInstance;
public static InputMethodManager getInstance() {
    synchronized (InputMethodManager.class) {
        if (sInstance == null) {
            IBinder b = ServiceManager.getService(Context.INPUT_METHOD_SERVICE);
            IInputMethodManager service = IInputMethodManager.Stub.asInterface(b);
            sInstance = new InputMethodManager(service, Looper.getMainLooper());
        }
        return sInstance;
    }
}

我们看到，其实这里是懒汉式（同步代码块）方式的改写，去掉了外部判断为空，放到了里面。然后通过ServiceManger.getService()方法，通过容器的方式获取了单例。

在Android很多系统服务都是通过容器获取的单例。

单例模式在日常开发中的应用场景

日常开发中我们也有些场景是需要用到单例模式的，例如：

1、图片加载
2、网络请求
3、工具类封装

案例有很多，相信大家也都有用到，我就不列举了。这里我们如何合理的在项目中使用单例模式。

合理的辨析一个设计是否应该为单例模式前，大家先问问自己几个问题，也是检验标准：

Quote from 《 Use your singletons wisely 》

Will every application use this class exactly the same way? (keyword: exactly)
Will every application ever need only one instance of this class? (keyword: ever & one)
Should the clients of this class be unaware of the application they are part of?

每一个应用（组件/模块）是否以完全一致的方式来使用这个类？
每一个应用（组件/模块）是否真的只需要这个类的一个实例呢？
对于这个类的客户端类来说，对他们自己是应用中的一部分这件事是否应该保持毫无察觉的状态呢？

以上3条就是检验一个类是否应该被设计为单例模式的判断准则，

如果我们对于以上这3条均给出了“是的”的答案，那么这个类就是可以被设计为单例模式了。反之还是不要用的好。

单例模式的优点

单例模式的优点其实已经在定义中提现了：可以减少系统内存开支，减少系统性能开销，避免对资源的多重占用、同时操作。

单例模式的缺点

任何事物都不是完美的，单例模式也是如此，它也存在以下几个缺点：

1、违反了单一责任链原则，测试困难

单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。

2、扩展困难

由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。修改功能必须修改源码。

3、共享资源有可能不一致。

现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致共享的单例对象状态的丢失。

总结

今天我们通过文章学习了第一个设计模式，了解了他的设计理念，学会了他的九种写法，也认识了他的优缺点。相信大家已经对单例模式有了一个全新的认识。（反正我写完文章才认识到自己原来根本不了解单例模式）

最后还是要给大家说一句话：模式是死的，代码是活的。不要硬套模式。代码会告诉你怎么做，你听就是了。（也是借鉴前辈们的经验）

设计模式目录

设计模式（一）—— 认识设计模式
设计模式（二）—— 技术直男正确“面向对象”的六大原则
设计模式（三）—— 单例模式
设计模式（四）—— 原型模式
设计模式（五）—— 简单工厂模式

参考资料

《设计模式——可复用面向对象软件的基础》
《Head First设计模式》
《大话设计模式》
《设计模式之禅》
《Android 源码设计模式解析与实战》

单例模式，这一篇差不多了 -- Singleton is an angel but an evil！
单例模式的八种写法比较
潜谈单例模式

刘伟

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