java/android 设计模式学习笔记(1)--- 单例模式

  前段时间公司一些同事在讨论单例模式(我是最渣的一个,都插不上嘴 T__T ),这个模式使用的频率很高,也多是不少人最熟悉的设计模式,固然单例模式也算是最简单的设计模式之一吧,简单归简单,可是在实际使用的时候也会有一些坑。
  PS:对技术感兴趣的同鞋加群544645972一块儿交流。html

设计模式总目录

  java/android 设计模式学习笔记目录 java

特色

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

  单例模式的使用很普遍,好比:线程池(threadpool)、缓存(cache)、对话框、处理偏好设置、和注册表(registry)的对象、日志对象,充当打印机、显卡等设备的驱动程序的对象等,这些类的对象只能有一个实例,若是制造出多个实例,就会致使不少问题的产生,程序的行为异常,资源使用过量,或者不一致的结果等,因此单例模式最主要的特色:android

  1. 构造函数不对外开放,通常为private;
  2. 经过一个静态方法或者枚举返回单例类对象;
  3. 确保单例类的对象有且只有一个,尤为是在多线程的环境下;
  4. 确保单例类对象在反序列化时不会从新构建对象。
经过将单例类构造函数私有化,使得客户端不能经过 new 的形式手动构造单例类的对象。单例类会暴露一个共有静态方法,客户端须要调用这个静态方法获取到单例类的惟一对象,在获取到这个单例对象的过程当中须要确保线程安全,即在多线程环境下构造单例类的对象也是有且只有一个,这是单例模式较关键的一个地方。
  • 主要优势
  • 单例模式的主要优势以下:
    1. 单例模式提供了对惟一实例的受控访问。由于单例类封装了它的惟一实例,因此它能够严格控制客户怎样以及什么时候访问它。
    2. 因为在系统内存中只存在一个对象,所以能够节约系统资源,对于一些须要频繁建立和销毁的对象单例模式无疑能够提升系统的性能。
    3. 容许可变数目的实例。基于单例模式咱们能够进行扩展,使用与单例控制类似的方法来得到指定个数的对象实例,既节省系统资源,又解决了单例对象共享过多有损性能的问题。
  • 主要缺点
    1. 因为单例模式中没有抽象层,所以单例类的扩展有很大的困难。
    2. 单例类的职责太重,在必定程度上违背了“单一职责原则”。由于单例类既充当了工厂角色,提供了工厂方法,同时又充当了产品角色,包含一些业务方法,将产品的建立和产品的自己的功能融合到一块儿。
    3. 如今不少面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术,所以,若是实例化的共享对象长时间不被利用,系统会认为它是垃圾,会自动销毁并回收资源,下次利用时又将从新实例化,这将致使共享的单例对象状态的丢失。
    4. 单例对象若是持有Context,那么很容易引起内存泄漏,此时须要注意传递给单例对象的Context最好是 Application Context。

UML类图

这里写图片描述

  类图很简单,Singleton 类有一个 static 的 instance对象,类型为 Singleton ,构造函数为 private,提供一个 getInstance() 的静态函数,返回刚才的 instance 对象,在该函数中进行初始化操做。git

示例与源码

  单例模式的写法不少,总结一下:程序员

lazy initialization, thread-unsafety(懒汉法,线程不安全)

  延迟初始化,通常不少人称为懒汉法,写法一目了然,在须要使用的时候去调用getInstance()函数去获取Singleton的惟一静态对象,若是为空,就会去作一个额外的初始化操做。github

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;
    }复制代码

可是套用《Head First》上的一句话,对于绝大部分不须要同步的状况来讲,synchronized 会让函数执行效率糟糕一百倍以上(Since synchronizing a method could in some extreme cases decrease performance by a factor of 100 or higher),因此就有了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 的性能影响。多线程

volatile关键字介绍

  double-checked方法用到了volatile关键字,volatile关键字的做用须要仔细介绍一下,在C/C++中,volatile关键字的做用和java中是不同的,总结一下:

  1. C/C++中的volatile关键字做用
    • 可见性
    • “可见性”指的是在一个线程中对该变量的修改会立刻由工做内存(Work Memory)写回主内存(Main Memory),因此会立刻反应在其它线程的读取操做中。顺便一提,工做内存和主内存能够近似理解为实际电脑中的高速缓存和主存,工做内存是线程独享的,主存是线程共享的。
    • 不可优化性
    • “不可优化”特性,volatile告诉编译器,不要对我这个变量进行各类激进的优化,甚至将变量直接消除,保证程序员写在代码中的指令,必定会被执行。
    • 顺序性
    • ”顺序性”,可以保证Volatile变量间的顺序性,编译器不会进行乱序优化。Volatile变量与非Volatile变量的顺序,编译器不保证顺序,可能会进行乱序优化。同时,C/C++ Volatile关键词,并不能用于构建happens-before语义,所以在进行多线程程序设计时,要当心使用volatile,不要掉入volatile变量的使用陷阱之中。
  2. java中volatile关键字做用
  3. 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].复制代码

因此对于 android 来讲,使用 volatile关键字是一点问题都没有的了。

  参考文章

  Volatile变量

  C/C++ Volatile关键词深度剖析

  Java中volatile的做用以及用法

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
  
  
  

 
  
  map = new HashMap 
 
  
    (); 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 类会初始化两次同样,这点须要注意。

  可是无论采起何种方案,请时刻牢记单例的三大要点:

  • 线程安全;
  • 延迟加载;
  • 序列化与反序列化安全。
  单例模式同时也有缺点:
  • 单例模式通常没有接口,扩展很困难,若要扩展,除了修改代码基本上没有第二种途径能够实现;
  • 单例对象若是持有 Context,那么很容易引起内存泄漏,此时须要注意传递给单例对象的 Context 最好为 Application Context。

建立型模式 Rules of thumb

  有些时候建立型模式是能够重叠使用的,有一些抽象工厂模式原型模式均可以使用的场景,这个时候使用任一设计模式都是合理的;在其余状况下,他们各自做为彼此的补充:抽象工厂模式可能会使用一些原型类来克隆而且返回产品对象。

  抽象工厂模式建造者模式原型模式都能使用单例模式来实现他们本身;抽象工厂模式常常也是经过工厂方法模式实现的,可是他们都可以使用原型模式来实现;

  一般状况下,设计模式刚开始会使用工厂方法模式(结构清晰,更容易定制化,子类的数量爆炸),若是设计者发现须要更多的灵活性时,就会慢慢地发展为抽象工厂模式原型模式或者建造者模式(结构更加复杂,使用灵活);

  原型模式并不必定须要继承,可是它确实须要一个初始化的操做,工厂方法模式必定须要继承,可是不必定须要初始化操做;

  使用装饰者模式或者组合模式的状况一般也可使用原型模式来得到益处;

  单例模式中,只要将构造方法的访问权限设置为 private 型,就能够实现单例。可是原型模式的 clone 方法直接无视构造方法的权限来生成新的对象,因此,单例模式原型模式是冲突的,在使用时要特别注意。

源码下载

  github.com/zhaozepeng/…

引用


www.tekbroaden.com/singleton-j…

hedengcheng.com/?p=725

www.cnblogs.com/hxsyl/archi…

www.blogjava.net/kenzhh/arch…

blog.csdn.net/jason0539/a…

sourcemaking.com/design_patt…

stackoverflow.com/questions/7…

stackoverflow.com/questions/1…

en.wikipedia.org/wiki/Single…

en.wikipedia.org/wiki/Double…

zh.wikipedia.org/wiki/Volati…

jeremymanson.blogspot.com/2008/11/wha…

www.jianshu.com/p/d8bf5d08a…

preshing.com/20130702/th…

blog.csdn.net/imzoer/arti…

相关文章
相关标签/搜索