阅读 731

单例模式(Singleton Pattern)

前言

:smile: 按照 001 篇讲的,以后的每个模式都将按照:模式名称、问题、解决方案以及效果这几个主要的要素研究。

  • 学习难度::smirk::smirk::smirk::smirk::smirk:
  • 使用频率::wink::wink::wink::wink::wink:

开始吧

模式名称

中文:单例模式

English: Singleton Pattern

含义:单例对象的类必须保证只有一个实例存在。

问题

何时使用

当我们需要统一管理资源,共享资源的时候就需要使用单例模式。保障

场景:

  1. Windows的Task(任务管理器) 就是很经典的单例模式。一台电脑正常情况下只能打开一个任务管理器。
  2. 网站的计数器,一般也采用单例模式实现,否则难以同步。
  3. 应用程序的日志应用,一般都才会用单例模式实现,这通常是由于共享的日志文件一直处于打开状态,因为只能有一个实例去操作,否则内容不好追加。
  4. Web应用的配置对象的读取,一般也应用单例模式,这个是由于配置文件是共享的资源。
  5. 数据库连接池的设计一般也是采用单例模式,因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池,主要是节省打开或者关闭数据库连接所引起的效率损耗,这种效率上的损耗还是非常昂贵的,因为何用单例模式来维护,就可以大大降低这种损耗。
  6. 多线程的线程池的设计一般也是采用单例模式,这是由于线程池要方便对池中的线程进行控制。
  7. 操作系统的文件系统,也是大的单例模式实现的具体例子,一个操作系统只能有一个文件系统。
  8. HttpApplication 也是单例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式,所有的HttpModule都共享一个HttpApplication实例.

存在的问题

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

请带着问题找答案:stuck_out_tongue_winking_eye:。

解决方案

来个UML图先

Singleton UML
Singleton UML


( Singleton UML )


科普一下:什么叫懒汉模式,什么叫饿汉模式

  • 懒汉模式 --> 特点是懒,不用的时候我就睡觉(不实例化)。
  • 饿汉模式 --> 特点是饿,一上来我就要吃(实例化)。

最简单的实现方法

// 懒汉,你不调用getInstance() 就不会实例化
public class Singleton {
    private static Singleton instance;
    public static Singleton getInstance() {
         if (instance == null) {
             instance = new Singleton();
         }
         return instance;
     }
}复制代码

解析:这是一个最简单的实现方法。通过 getInstance() 获取 Singleton 这个类的实例。instance == null 的情况下 new 一个实例。不为空就返回这个实例。可以说,这个方法最适合教学,一眼就能看的很明白什么是单例。

BUT , 想一想,我是不是在外面也能 通过 new Singleton() 来创建一个实例 ?那都是多个实例了。还怎么单例?

So ,我们要开始进阶了。脱离学生手法,开始进阶。

// 懒汉,你不调用getInstance() 就不会实例化
public class Singleton {
    private static Singleton instance;
    public static Singleton getInstance() {
         if (instance == null) {
             instance = new Singleton();
         }
         return instance;
     }
     // add 1.1 begin (将构造方法私有化)
     private Singleton() {
     }
     // add 1.1 end
}复制代码

经过 v1.1 版本的改造。发现在外面再也 new 不出来 Singleton 的实例。:stuck_out_tongue: 我学会了?给你个眼神:smirk:

我们再想:两个线程几乎同时调用 getInstance() 第一个进入的线程判断 instance 为空,开始走这一行 instance = new Singleton();。,注意,是开始走这一行,并未完成实例化! 此时第二个线程也走到 if (instance == null)此时判断也为空。那么 这两个线程都会得到一个新的实例,那么就产生两个实例。那么还怎么单例?

以上为懒汉模式 -- (线程不安全)

懒汉模式 - 线程安全

为了解决 上面那个方法在多线程下使用不安全的问题。我们再次进阶。
这次吊了�这从线程安全了!

我反手就给你一段代码

// 懒汉,你不调用getInstance() 就不会实例化
public class Singleton {
    private static Singleton instance;
    // modif synchronized
    public static synchronized  Singleton getInstance() {
         if (instance == null) {
             instance = new Singleton();
         }
         return instance;
     }
     // add 1.1 begin (将构造方法私有化)
     private Singleton() {
     }
     // add 1.1 end
}复制代码

看,加一个synchronized同步,来一个要等着。等里面的代码执行完了,第二个线程再进去。第二个再进去的时候,instance就不是空了,就又能单例了。��


Too young。这样搞的话,我们每次进来都可能要同步一下。多数时候我们并不是两个或多个线程同时来访问,我们并不需要去同步。这样做其实造成了不必要的开销。有木有更好的方法呢?


Double Checked locking pattern 【 双重检验锁 】



我反手又是一串代码(关键代码)

只贴上关键代码。才好

public static Singleton getInstance() {
    if (instance == null) {               //Single Checked
        synchronized (Singleton.class) {
            if (instance == null) {       //Double Checked
                instance = new Singleton();
            }
        }
    }
    return instance ;
}复制代码

看到没,你想到这样搞了吗? 先检测再同步。Single Checked足以应付多数检测。当一个以上的线程同时访问时就用上了Double Checked防止多线程下重复创建实例。 �即使我们这么想到这么吊的方法,还是不行。。。为啥?

为啥? instance = new Singleton() 这个不是原子操作。当我们 new 的时候 JVM 大概做了这些事:

  1. instance分配内存
  2. 调用 Singleton的构造函数,来初始化成员变量
  3. instance对象指向分配的内存空间(执行完这步 instance 就不为 null 了)

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的,最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者,则在 3 执行完毕、2 未执行之前,被线程二抢占了,这时 instance 已经是非 null 了(但却没有初始化),所以线程二会直接返回 instance,然后使用,然后顺理成章地报错。

解决方法也很简单:加上 volatile 就可以了。使用 volatile 的主要原因是其一个特性:禁止指令重排序优化

 private volatile static Singleton instance; //声明成 volatile复制代码

注意: 在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM (Java 内存模型)是存在缺陷的,即时将变量声明成 volatile 也不能完全避免重排序,主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复,所以在这之后才可以放心使用 volatile。


注解
原子操作:
如果这个操作所处的层(layer)的更高层不能发现其内部实现与结构,那么这个操作是一个原子(atomic)操作。
原子操作可以是一个步骤,也可以是多个操作步骤,但是其顺序不可以被打乱,也不可以被切割而只执行其中的一部分。
将整个操作视作一个整体是原子性的核心特征。

这个方法解决了上面所有的不安全因素,但是!在 Java 5 以前的版本上跑却还是会有问题,所以,这个也不是最好的方法。。。

饿汉来了

public class Singleton {  
    private static Singleton instance = new Singleton();
    private Singleton (){}
    public static Singleton getInstance() {
      return instance;
    }复制代码

是这样的,因为单例的实例 instance 被声明称 staticfinal 了,在第一次加载类到内存中就会被实例化。所以创建实例本身是线程安全的。一上来就加载,所以是饿汉。

缺点:太着急加载。有时候我们想加点料也不给机会。有时候我们创建实例需要依赖参数或者配置文件。这样就不能使用饿汉模式。�

怎么办?

内部静态类

先瞅代码

public class Singleton {
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
    private Singleton() {}
    public static final Singleton getInstance(int a) {
        return SingletonHolder.INSTANCE;
    }
}复制代码

由于 SingletonHolder 是私有的,除了 getInstance() 之外没有办法访问它,因此它是懒汉式的;同时读取实例的时候不会进行同步,没有性能缺陷;也不依赖 JDK 版本。能完美应对多数场景。如果你觉得写着麻烦,其实还有这一种很简单的写法。好像不太常用。就是下面这个枚举

枚举单例

《Effective Java》:单元素的枚举类型已经成为实现Singleton的最佳方法

public enum Singleton {
     //理解为 public static final Singleton INSTANCE;
     INSTANCE;
 }复制代码

实例化:Singleton.INSTANCE 就是这么简单。但是单例这样用的人我觉得还是不多。猜想是大家对枚举了解不太多吧。如果看到枚举这个方式一脸懵B,就看看枚举相关的知识。反正我一开始也是一脸**

效果

以上介绍了:

  • 简单写法(入门)
  • 懒汉模式线程安全
  • 双重检验锁(DLC)
  • 饿汉模式
  • 内部静态类
  • 枚举

几种方法不重要。最重要的知道什么是单例模式,为啥用单例。甚至不在代码中使用,工作、生活、学习、游戏中充满单例思想。掌握这个思想以及解决办法,生活会很精彩��

再说一下:《Effective Java》推荐 DLC 和枚举,那些明显有问题的写法就不要用了。那些写法都是用来教学理解单例的。


更新中:
1. 什么是设计模式
2. 单例模式
3. 简单工厂模式
GitHub汇总:这里总是最新的
看完给个star鼓励一下

关注下面的标签,发现更多相似文章
评论