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

  前段时间公司一些同事在讨论单例模式(我是最渣的一个,都插不上嘴 T__T ),这个模式使用的频率很高,也可能是很多人最熟悉的设计模式,当然单例模式也算是最简单的设计模式之一吧,简单归简单,但是在实际使用的时候也会有一些坑。

  PS:对技术感兴趣的同鞋加群544645972一起交流

设计模式总目录

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

特点

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

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

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

通过将单例类构造函数私有化,使得客户端不能通过 new 的形式手动构造单例类的对象。单例类会暴露一个共有静态方法,客户端需要条用这个静态方法获取到单例类的唯一对象,在获取到这个单例对象的过程中需要确保线程安全,即在多线程环境下构造单例类的对象也是有且只有一个,这是单例模式较关键的一个地方。

  • 主要优点
  • 单例模式的主要优点如下:

    1. 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例,所以它可以严格控制客户怎样以及何时访问它。
    2. 由于在系统内存中只存在一个对象,因此可以节约系统资源,对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
    3. 允许可变数目的实例。基于单例模式我们可以进行扩展,使用与单例控制相似的方法来获得指定个数的对象实例,既节省系统资源,又解决了单例对象共享过多有损性能的问题。
  • 主要缺点
    1. 由于单例模式中没有抽象层,因此单例类的扩展有很大的困难。
    2. 单例类的职责过重,在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色,提供了工厂方法,同时又充当了产品角色,包含一些业务方法,将产品的创建和产品的本身的功能融合到一起。
    3. 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术,因此,如果实例化的共享对象长时间不被利用,系统会认为它是垃圾,会自动销毁并回收资源,下次利用时又将重新实例化,这将导致共享的单例对象状态的丢失。

UML类图

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

示例与源码

  单例模式的写法很多,总结一下:

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

  延迟初始化,一般很多人称为懒汉法,写法一目了然,在需要使用的时候去调用getInstance()函数去获取Singleton的唯一静态对象,如果为空,就会去做一个额外的初始化操作。

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<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 类会初始化两次一样,这点需要注意。

  但是不管采取何种方案,请时刻牢记单例的三大要点:

  • 线程安全
  • 延迟加载
  • 序列化与反序列化安全

源码下载

  https://github.com/zhaozepeng/Design-Patterns

引用

http://www.tekbroaden.com/singleton-java.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

http://hedengcheng.com/?p=725

http://www.cnblogs.com/hxsyl/archive/2013/03/19/2969489.html

http://www.blogjava.net/kenzhh/archive/2013/03/15/357824.html

http://blog.csdn.net/jason0539/article/details/23297037

https://sourcemaking.com/design_patterns/singleton

http://stackoverflow.com/questions/70689/what-is-an-efficient-way-to-implement-a-singleton-pattern-in-java

http://stackoverflow.com/questions/15792186/singleton-pattern-with-combination-of-lazy-loading-and-thread-safety

https://en.wikipedia.org/wiki/Singleton_pattern

https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

https://zh.wikipedia.org/wiki/Volatile%E5%8F%98%E9%87%8F

http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html

http://www.jianshu.com/p/d8bf5d08a147

http://preshing.com/20130702/the-happens-before-relation/

http://blog.csdn.net/imzoer/article/details/8620801

时间: 04-24

java/android 设计模式学习笔记(一)---单例模式的相关文章

java/android 设计模式学习笔记(2)---观察者模式

这篇来讲一下观察者模式,观察者模式在实际项目中使用的也是非常频繁的,它最常用的地方是GUI系统.订阅--发布系统等.因为这个模式的一个重要作用就是解耦,使得它们之间的依赖性更小,甚至做到毫无依赖.以GUI系统来说,应用的UI具有易变性,尤其是前期随着业务的改变或者产品的需求修改,应用界面也经常性变化,但是业务逻辑基本变化不大,此时,GUI系统需要一套机制来应对这种情况,使得UI层与具体的业务逻辑解耦,观察者模式此时就派上用场了. PS:对技术感兴趣的同鞋加群544645972一起交流. 设计模式

java/android 设计模式学习笔记(5)---对象池模式

这次要介绍一下对象池模式(Object Pool Pattern),这个模式为常见 23 种设计模式之外的设计模式,介绍的初衷主要是在平时的 android 开发中经常会看到,比如 ThreadPool 和 MessagePool 等. 在 java 中,所有对象的内存由虚拟机管理,所以在某些情况下,需要频繁创建一些生命周期很短使用完之后就可以立即销毁,但是数量很大的对象集合,那么此时 GC 的次数必然会增加,这时候为了减小系统 GC 的压力,对象池模式就很适用了.对象池模式也是创建型模式之一,

java/android 设计模式学习笔记(14)---外观模式

这篇博客来介绍外观模式(Facade Pattern),外观模式也称为门面模式,它在开发过程中运用频率非常高,尤其是第三方 SDK 基本很大概率都会使用外观模式.通过一个外观类使得整个子系统只有一个统一的高层的接口,这样能够降低用户的使用成本,也对用户屏蔽了很多实现细节.当然,在我们的开发过程中,外观模式也是我们封装 API 的常用手段,例如网络模块.ImageLoader 模块等.其实我们在开发过程中可能已经使用过很多次外观模式,只是没有从理论层面去了解它. 转载请注明出处:http://bl

java/android 设计模式学习笔记(10)---建造者模式

这篇博客我们来介绍一下建造者模式(Builder Pattern),建造者模式又被称为生成器模式,是创造性模式之一,与工厂方法模式和抽象工厂模式不同,后两者的目的是为了实现多态性,而 Builder 模式的目的则是为了将对象的构建与展示分离.Builder 模式是一步一步创建一个复杂对象的创建型模式,它允许用户在不知道内部构建细节的情况下,可以更精细地控制对象的构造流程.一个复杂的对象有大量的组成部分,比如汽车它有车轮.方向盘.发动机.以及各种各样的小零件,要将这些部件装配成一辆汽车,这个装配过

java/android 设计模式学习笔记(7)---装饰者模式

这篇将会介绍装饰者模式(Decorator Pattern),装饰者模式也称为包装模式(Wrapper Pattern),结构型模式之一,其使用一种对客户端透明的方式来动态的扩展对象的功能,同时它也是继承关系的一种替代方案之一,但比继承更加灵活.在现实生活中也可以看到很多装饰者模式的例子,或者可以大胆的说装饰者模式无处不在,就拿一件东西来说,可以给它披上无数层不一样的外壳,但是这件东西还是这件东西,外壳不过是用来扩展这个东西的功能而已,这就是装饰者模式,装饰者的这个角色也许各不相同但是被装饰的对

java/android 设计模式学习笔记(13)---享元模式

这篇我们来介绍一下享元模式(Flyweight Pattern),Flyweight 代表轻量级的意思,享元模式是对象池的一种实现.享元模式用来尽可能减少内存使用量,它适合用于可能存在大量重复对象的场景,缓存可共享的对象,来达到对象共享和避免创建过多对象的效果,这样一来就可以提升性能,避免内存移除和频繁 GC 等. 享元模式的一个经典使用案例是文本系统中图形显示所用的数据结构,一个文本系统能够显示的字符种类就是那么几十上百个,那么就定义这么些基础字符对象,存储每个字符的显示外形和其他的格式化数据

java/android 设计模式学习笔记(12)---组合模式

这篇我们来介绍一下组合模式(Composite Pattern),它也称为部分整体模式(Part-Whole Pattern),结构型模式之一.组合模式比较简单,它将一组相似的对象看作一个对象处理,并根据一个树状结构来组合对象,然后提供一个统一的方法去访问相应的对象,以此忽略掉对象与对象集合之间的差别.这个最典型的例子就是数据结构中的树了,如果一个节点有子节点,那么它就是枝干节点,如果没有子节点,那么它就是叶子节点,那么怎么把枝干节点和叶子节点统一当作一种对象处理呢?这就需要用到组合模式了. 转

java/android 设计模式学习笔记(9)---代理模式

这篇博客我们来介绍一下代理模式(Proxy Pattern),代理模式也成为委托模式,是一个非常重要的设计模式,不少设计模式也都会有代理模式的影子.代理在我们日常生活中也很常见,比如上网时连接的代理服务器地址,更比如我们平时租房子,将找房子的过程代理给中介等等,都是代理模式在日常生活中的使用例子. 代理模式中的代理对象能够连接任何事物:一个网络连接,一个占用很多内存的大对象,一个文件,或者是一些复制起来代价很高甚至根本不可能复制的一些资源.总之,代理是一个由客户端调用去访问幕后真正服务的包装对象

java/android 设计模式学习笔记(6)---适配器模式

这篇来介绍一下适配器模式(Adapter Pattern),适配器模式在开发中使用的频率也是很高的,像 ListView 和 RecyclerView 的 Adapter 等都是使用的适配器模式.在我们的实际生活中也有很多类似于适配器的例子,比如香港的插座和大陆的插座就是两种格式的,为了能够成功适配,一般会在中间加上一个电源适配器,形如: 这样就能够将原来不符合的现有系统和目标系统通过适配器成功连接. 说到底,适配器模式是将原来不兼容的两个类融合在一起,它有点类似于粘合剂,将不同的东西通过一种转