设计模式：单例模式

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

单例模式的使用很广泛，比如：线程池（threadpool）、缓存（cache）、对话框、处理偏好设置、和注册表（registry）的对象、日志对象，充当打印机、显卡等设备的驱动程序的对象等，这些类的对象只能有一个实例，如果制造出多个实例，就会导致很多问题的产生，程序的行为异常，资源使用过量，或者不一致的结果等

特点

  • 构造函数不对外开放，一般为private；
  • 通过一个静态方法或者枚举返回单例类对象；
  • 确保单例类的对象有且只有一个，尤其是在多线程的环境下；
  • 确保单例类对象在反序列化时不会重新构建对象。
  • 通过将单例类构造函数私有化，使得客户端不能通过 new 的形式手动构造单例类的对象。单例类会暴露一个共有静态方法，客户端需要调用这个静态方法获取到单例类的唯一对象，在获取到这个单例对象的过程中需要确保线程安全，即在多线程环境下构造单例类的对象也是有且只有一个，这是单例模式较关键的一个地方。

主要优点

  • 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它。
  • 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
  • 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例，既节省系统资源，又解决了单例对象共享过多有损性能的问题。

主要缺点

  • 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。

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

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

  • 单例对象如果持有Context，那么很容易引发内存泄漏，此时需要注意传递给单例对象的Context最好是 Application Context。

类图

单例模式

写法

lazy initialization, thread-unsafety（懒汉法，线程不安全）

public class Singleton {

    private static Singleton instance = null;

    private Singleton(){}

    public static Singleton getInstance() {

        if(instance == null) 
            instance = new Singleton();//用到的时候才初始化
        return instance;
    }

}

需要注意的是这种写法在多线程操作中是不安全的，后果是可能会产生多个Singleton对象，比如两个线程同时执行getInstance()函数时，然后同时执行到 new 操作时，最后很有可能会创建两个不同的对象。

lazy initialization, thread-safety, double-checked(懒汉法，线程安全)

需要做到线程安全，就需要确保任意时刻只能有且仅有一个线程能够执行new Singleton对象的操作，所以可以在getInstance()函数上加上 synchronized 关键字，类似于：

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

double-checked（双重检测）

但是套用《Head First》上的一句话，对于绝大部分不需要同步的情况来说，synchronized 会让函数执行效率糟糕一百倍以上（Since synchronizing a method could in some extreme cases decrease performance by a factor of 100 or higher），所以就有了double-checked（双重检测）的方法：

//double-checked（双重检测）
public class Singleton {
private volatile static Singleton instance = null;
private Singleton(){}
public static Singleton getInstance() {
    if (instance == null){
        synchronized (Singleton.class){
            if (instance == null){
                instance = new Singleton();
            }
        }
    }
    return instance;
 }
}

我们假设两个线程A,B同时执行到了getInstance()这个方法，第一个if判断，两个线程同时为true，进入if语句，里面有个 synchronized 同步，所以之后有且仅有一个线程A会执行到 synchronized 语句内部，接着再次判断instance是否为空，为空就去new Singleton对象并且赋值给instance，A线程退出 synchronized 语句，交出同步锁，B线程进入 synchronized 语句内部，if判断instance是否为空，防止创建不同的instance对象，这也是第二个if判断的作用，B线程发现不为空，所以直接退出，所以最终A和B线程可以获取到同一个Singleton对象，之后的线程调用getInstance()函数，都会因为Instance不为空而直接返回，不会受到 synchronized 的性能影响。

java中volatile关键字作用
Java也支持volatile关键字，但它被用于其他不同的用途。当volatile用于一个作用域时，Java保证如下：
（适用于Java所有版本）读和写一个volatile变量有全局的排序。也就是说每个线程访问一个volatile作用域时会在继续执行之前读取它的当前值，而不是（可能）使用一个缓存的值。(但是并不保证经常读写volatile作用域时读和写的相对顺序，也就是说通常这并不是有用的线程构建)。
（适用于Java5及其之后的版本）volatile的读和写建立了一个happens-before关系，类似于申请和释放一个互斥锁[8]。
使用volatile会比使用锁更快，但是在一些情况下它不能工作。volatile使用范围在Java5中得到了扩展，特别是双重检查锁定现在能够正确工作[9]。
上面有一个细节，java 5版本之后volatile的读与写才建立了一个happens-before的关系，之前的版本会出现一个问题：Why is volatile used in this example of double checked locking，这个答案写的很清楚了，线程 A 在完全构造完 instance 对象之前就会给 instance 分配内存，线程B在看到 instance 已经分配了内存不为空就回去使用它，所以这就造成了B线程使用了部分初始化的 instance 对象，最后就会出问题了。Double-checked locking里面有一句话

As of J2SE 5.0, this problem has been fixed. The volatile keyword now ensures that multiple threads handle the singleton instance correctly. This new idiom is
described in [2] and [3].

eager initialization thread-safety （饿汉法，线程安全）

“饿汉法”就是在使用该变量之前就将该变量进行初始化，这当然也就是线程安全的了，写法也很简单：

private static Singleton instance = new Singleton();

private Singleton(){
    name = "eager initialization thread-safety  1";

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

或者

private static Singleton instance  = null;

private Singleton(){
    name = "eager initialization thread-safety  2";
}

static {
    instance = new Singleton();
}

public Singleton getInstance(){
    return instance;
}

代码都很简单，一个是直接进行初始化，另一个是使用静态块进行初始化，目的都是一个：在该类进行加载的时候就会初始化该对象，而不管是否需要该对象。这么写的好处是编写简单，而且是线程安全的，但是这时候初始化instance显然没有达到lazy loading的效果。

static inner class thread-safety （静态内部类，线程安全）

由于在java中，静态内部类是在使用中初始化的，所以可以利用这个天生的延迟加载特性，去实现一个简单，延迟加载，线程安全的单例模式：

private static class SingletonHolder{
    private static final Singleton instance = new Singleton();
}

private Singleton(){
    name = "static inner class thread-safety";
}

public static Singleton getInstance(){
    return SingletonHolder.instance;
}

定义一个 SingletonHolder 的静态内部类，在该类中定义一个外部类 Singleton 的静态对象，并且直接初始化，在外部类 Singleton 的 getInstance() 方法中直接返回该对象。由于静态内部类的使用是延迟加载机制，所以只有当线程调用到 getInstance() 方法时才会去加载 SingletonHolder 类，加载这个类的时候又会去初始化 instance 变量，所以这个就实现了延迟加载机制，同时也只会初始化这一次，所以也是线程安全的，写法也很简单。

PS
　　上面提到的所有实现方式都有两个共同的缺点：
都需要额外的工作(Serializable、transient、readResolve())来实现序列化，否则每次反序列化一个序列化的对象实例时都会创建一个新的实例。
可能会有人使用反射强行调用我们的私有构造器（如果要避免这种情况，可以修改构造器，让它在创建第二个实例的时候抛异常）。

enum （枚举写法）

JDK1.5 之后加入 enum 特性，可以使用 enum 来实现单例模式：

enum SingleEnum{
    INSTANCE("enum singleton thread-safety");
    private String name;
    SingleEnum(String name){
        this.name = name;
    }
    public String getName(){
        return name;
    }
}

使用枚举除了线程安全和防止反射强行调用构造器之外，还提供了自动序列化机制，防止反序列化的时候创建新的对象。因此，Effective Java推荐尽可能地使用枚举来实现单例。但是很不幸的是 android 中并不推荐使用 enum ，主要是因为在 java 中枚举都是继承自 java.lang.Enum 类，首次调用时，这个类会调用初始化方法来准备每个枚举变量。每个枚举项都会被声明成一个静态变量，并被赋值。在实际使用时会有点问题，这是 google 的官方文档介绍：
Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android
这篇博客也专门计算了 enum 的大小：胡凯-The price of ENUMs，所以枚举写法的缺点也就很明显了。

登记式

登记式单例实际上维护了一组单例类的实例，将这些实例存放在一个Map（登记薄）中，对于已经登记过的实例，则从Map直接返回，对于没有登记的，则先登记，然后返回。

//类似Spring里面的方法，将类名注册，下次从里面直接获取。  

public class Singleton {  
private static Map<String,Singleton> map = new HashMap<String,Singleton>();  
static{  
    Singleton single = new Singleton();  //构造了一个简单的实例
    map.put(single.getClass().getName(), single);  
}  
//保护的默认构造子  
protected Singleton(){}  
//静态工厂方法,返还此类惟一的实例  
public static Singleton getInstance(String name) {  
    if(name == null) {  
        name = Singleton.class.getName();  
        System.out.println("name == null"+"--->name="+name);  
    }  
    if(map.get(name) == null) {  
        try {  
            map.put(name, (Singleton) Class.forName(name).newInstance());  
        } catch (InstantiationException e) {  
            e.printStackTrace();  
        } catch (IllegalAccessException e) {  
            e.printStackTrace();  
        } catch (ClassNotFoundException e) {  
            e.printStackTrace();  
        }  
    }  
    return map.get(name);  
}  
//一个示意性的商业方法  
public String about() {      
    return "Hello, I am RegSingleton.";      
}      
public static void main(String[] args) {  
    Singleton single3 = Singleton.getInstance(null);  
    System.out.println(single3.about());  
}  
}

这种方式我极少见到，另外其实内部实现还是用的饿汉式单例，因为其中的static方法块，它的单例在类被装载的时候就被实例化了。

总结
　　综上所述，平时在 android 中使用** double-checked **或者 SingletonHolder 都是可以的，毕竟 android 早就不使用 JDK5 之前的版本了。由于 android 中的多进程机制，在不同进程中无法创建同一个 instance 变量，就像 Application 类会初始化两次一样，这点需要注意。

创建型模式 Rules of thumb

有些时候创建型模式是可以重叠使用的，有一些抽象工厂模式和原型模式都可以使用的场景，这个时候使用任一设计模式都是合理的；在其他情况下，他们各自作为彼此的补充：抽象工厂模式可能会使用一些原型类来克隆并且返回产品对象。
　　抽象工厂模式，建造者模式和原型模式都能使用单例模式来实现他们自己；抽象工厂模式经常也是通过工厂方法模式实现的，但是他们都能够使用原型模式来实现；
　　通常情况下，设计模式刚开始会使用工厂方法模式（结构清晰，更容易定制化，子类的数量爆炸），如果设计者发现需要更多的灵活性时，就会慢慢地发展为抽象工厂模式，原型模式或者建造者模式（结构更加复杂，使用灵活）；
　　原型模式并不一定需要继承，但是它确实需要一个初始化的操作，工厂方法模式一定需要继承，但是不一定需要初始化操作；
　　使用装饰者模式或者组合模式的情况通常也可以使用原型模式来获得益处；
　　单例模式中，只要将构造方法的访问权限设置为 private 型，就可以实现单例。但是原型模式的 clone 方法直接无视构造方法的权限来生成新的对象，所以，单例模式与原型模式是冲突的，在使用时要特别注意。

转载ref: java/android 设计模式学习笔记（1）---单例模式

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