简介
为什么使用该模式？
- 处理资源的访问冲突
- 表示资源/信息的唯一性
单例模式的特点
实现单例模式的几种方式
静态内部类
枚举
单例模式存在的问题
单例的替代方案
- 静态方法
- 依赖注入
单例的唯一性
- 线程的唯一性
单例模式和静态方法

简介

什么是单例模式？即某个类只允许创建一个实体对象，那么这个类就是单例类，这种设计模式就是单例模式。

为什么使用该模式？

处理资源的访问冲突

关于资源文件的访问冲突有多种的解决方式，比如类锁：

synchronized(ClassA.class) {
    // 括号内的代码一个时间只允许一个线程访问，会阻塞其他线程
}

还有类似并发队列的方式，使用BlockingQueen来存放task，多线程往这个队列里丢task，然后单独一个线程去处理每个task。

单例方式也可以解决资源的访问冲突。但是前提是对这个资源的访问方法是对象级别的线程安全的，即只有一个对象时，多个线程操作该对象能不影响/冲突。

表示资源/信息的唯一性

如果某些数据在全局只存在一份，且具有共享性，则可以用作单例模式。

单例模式的特点

构造函数需要是 private 访问权限的，这样才能避免外部通过 new 创建实例；
考虑对象创建时的线程安全问题；
考虑是否支持延迟加载；
考虑 getInstance() 性能是否高（是否加锁）。

实现单例模式的几种方式

饿汉式

饿汉式的实现方式比较简单。在类加载的时候，instance 静态实例就已经创建并初始化好了，所以，instance 实例的创建过程是线程安全的。不过，这样的实现方式不支持延迟加载（在真正用到 IdGenerator 的时候，再创建实例），从名字中我们也可以看出这一点。

class IdGenerator {
    private static final IdGenerator instance = new IdGenerator();
    private IdGenerator() {} 
    public static IdGenerator getInstance() { return instance; }
}

一些缺点：不支持延迟加载，如果实例占用资源多（比如占用内存多）或初始化耗时长（比如需要加载各种配置文件），提前初始化实例是一种浪费资源的行为。最好的方法应该在用到的时候再去初始化。

但是在Android中由于要提高首屏打开的速度，如果在loadClass时时间较长，则影响了首屏的打开时间，用户对于首屏打开时间是敏感的，而对于首屏打开后的loading/略有卡顿敏感度较低，且大量Class在一个时间初始化可能导致抢占时间片轮，ANR的情况。懒汉式还是饿汉式更好需要看具体的场景。对于那些短生命周期的应用，如客户端应用来说，启动是频繁发生的，如果启动时导致了一堆饿汉初始化，会给用户带来不好的体验，如果把初始化往后延，将初始化分散在未来的各个时间点，即使某个懒汉初始化时间较长，用户也几乎无感知。而对于生命周期较长的应用，长痛不如短痛，启动时耗点时，保证后面的使用流畅也是可取的。

如果初始化耗时长，那我们最好不要等到真正要用它的时候，才去执行这个耗时长的初始化过程，这会影响到系统的性能（比如，在响应客户端接口请求的时候，做这个初始化操作，会导致此请求的响应时间变长，甚至超时）。采用饿汉式实现方式，将耗时的初始化操作，提前到程序启动的时候完成，这样就能避免在程序运行的时候，再去初始化导致的性能问题。

如果实例占用资源多，按照 fail-fast 的设计原则（有问题及早暴露），那我们也希望在程序启动时就将这个实例初始化好。如果资源不够，就会在程序启动的时候触发报错（比如 Java 中的 PermGen Space OOM），我们可以立即去修复。这样也能避免在程序运行一段时间后，突然因为初始化这个实例占用资源过多，导致系统崩溃，影响系统的可用性。

懒汉式

懒汉式相对于饿汉式的优势是支持延迟加载。

public class IdGenerator { 
    private static IdGenerator instance; 
    private IdGenerator() {} 
    public static synchronized IdGenerator getInstance() { 
        if (instance == null) { 
            instance = new IdGenerator(); 
        } 
        return instance; 
    }    
}

懒汉式的缺点也很明显，我们给 getInstance() 这个方法加了一把大锁（synchronzed），导致这个函数的并发度很低。量化一下的话，并发度是 1，也就相当于串行操作了。而这个函数是在单例使用期间，一直会被调用。如果这个单例类偶尔会被用到，那这种实现方式还可以接受。但是，如果频繁地用到，那频繁加锁、释放锁及并发度低等问题，会导致性能瓶颈，这种实现方式就不可取了。

带有双重检测的懒汉式

饿汉式不支持延迟加载，懒汉式有性能问题，不支持高并发。那我们再来看一种既支持延迟加载、又支持高并发的单例实现方式，也就是双重检测实现方式。

在这种实现方式中，只要 instance 被创建之后，即便再调用 getInstance() 函数也不会再进入到加锁逻辑中了。所以，这种实现方式解决了懒汉式并发度低的问题。

public class IdGenerator { 
  private static IdGenerator instance;
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    if (instance == null) {
      synchronized(IdGenerator.class) { // 此处为类级别的锁
        if (instance == null) {
          instance = new IdGenerator();
        }
      }
    }
    return instance;
  }
}

指令重排序

因为指令重排序，可能会导致 IdGenerator 对象被 new 出来，并且赋值给 instance 之后，还没来得及初始化（执行构造函数中的代码逻辑），就被另一个线程使用了。

要解决这个问题，我们需要给 instance 成员变量加上 volatile 关键字，禁止指令重排序才行。实际上，只有很低版本的 Java 才会有这个问题。我们现在用的高版本(jdk8已经确保new、初始化为原子性操作，不会出现JIT导致指令重排的情况)的 Java 已经在 JDK 内部实现中解决了这个问题（解决的方法很简单，只要把对象 new 操作和初始化操作设计为原子操作，就自然能禁止重排序）。

静态内部类

public class IdGenerator { 
  private IdGenerator() {}
  private static class SingletonHolder{
    private static final IdGenerator instance = new IdGenerator();
  }
  public static IdGenerator getInstance() {
    return SingletonHolder.instance;
  }
}

SingletonHolder 是一个静态内部类，当外部类 IdGenerator 被加载的时候，并不会创建 SingletonHolder 实例对象。只有当调用 getInstance() 方法时，SingletonHolder 才会被加载，这个时候才会创建 instance。instance 的唯一性、创建过程的线程安全性，都由 JVM 来保证。所以，这种实现方法既保证了线程安全，又能做到延迟加载。

枚举

public enum IdGenerator {
  INSTANCE;
  private AtomicLong id = new AtomicLong(0);
  public long getId() { 
    return id.incrementAndGet();
  }
}

枚举模式的单例还可以防止序列化和反序列化生成新的实例。

单例模式存在的问题

单例对 OOP 特性的支持不友好

OOP 的四大特性是封装、抽象、继承、多态。单例这种设计模式对于其中的抽象、继承、多态都支持得不好。

单例的使用方式违背了基于接口而非实现的设计原则，也就违背了广义上理解的 OOP 的抽象特性。如果未来某一天，我们希望针对不同的业务采用不同的 ID 生成算法。比如，订单 ID 和用户 ID 采用不同的 ID 生成器来生成。为了应对这个需求变化，我们需要修改所有用到 IdGenerator 类的地方，这样代码的改动就会比较大。

单例会隐藏类之间的依赖关系

我们知道，代码的可读性非常重要。在阅读代码的时候，我们希望一眼就能看出类与类之间的依赖关系，搞清楚这个类依赖了哪些外部类。

通过构造函数、参数传递等方式声明的类之间的依赖关系，我们通过查看函数的定义，就能很容易识别出来。但是，单例类不需要显示创建、不需要依赖参数传递，在函数中直接调用就可以了。如果代码比较复杂，这种调用关系就会非常隐蔽。在阅读代码的时候，我们就需要仔细查看每个函数的代码实现，才能知道这个类到底依赖了哪些单例类。

单例对代码的扩展性不友好

单例类在某些情况下会影响代码的扩展性、灵活性。所以，数据库连接池、线程池这类的资源池，最好还是不要设计成单例类。实际上，一些开源的数据库连接池、线程池也确实没有设计成单例类。

单例对代码的可测试性不友好

单例模式的使用会影响到代码的可测试性。如果单例类依赖比较重的外部资源，比如 DB，我们在写单元测试的时候，希望能通过 mock 的方式将它替换掉。而单例类这种硬编码式的使用方式，导致无法实现 mock 替换。

除此之外，如果单例类持有成员变量（比如 IdGenerator 中的 id 成员变量），那它实际上相当于一种全局变量，被所有的代码共享。如果这个全局变量是一个可变全局变量，也就是说，它的成员变量是可以被修改的，那我们在编写单元测试的时候，还需要注意不同测试用例之间，修改了单例类中的同一个成员变量的值，从而导致测试结果互相影响的问题。

单例不支持有参数的构造函数

可以通过对单例的一些拓展调整实现该功能。

单例的替代方案

静态方法

不灵活，无法实现延迟加载等。

依赖注入

将单例对象当作参数传递，以解耦，隐藏类之间的依赖关系。

单例的唯一性

单例是相对于进程唯一的，即一个进程只有一个该类的实例，所以在单例的初始化时需要使用synchronized关键字来进行约束，避免多线程同时初始化造成多个实例。进程的唯一则表明进程之间可以有多份，单个进程内只有一份，而线程更是依附于进程的，所以单个线程也只有一份。

线程的唯一性

线程的唯一性表示线程内只有一个，进程内可以存在多份，比较典型的例子就是Android中的Looper对象，创建的Looper对象都是单个线程独有的。

我们通过一个 HashMap 来存储对象，其中 key 是线程 ID，value 是对象。这样我们就可以做到，不同的线程对应不同的对象，同一个线程只能对应一个对象。实际上，Java 语言本身提供了 ThreadLocal 工具类，可以更加轻松地实现线程唯一单例。不过，ThreadLocal 底层实现原理也是基于下面代码中所示的 HashMap。

public class IdGenerator {
  private AtomicLong id = new AtomicLong(0);
  private static final ConcurrentHashMap<Long, IdGenerator> instances
          = new ConcurrentHashMap<>();
  private IdGenerator() {}
  public static IdGenerator getInstance() {
    Long currentThreadId = Thread.currentThread().getId();
    instances.putIfAbsent(currentThreadId, new IdGenerator());
    return instances.get(currentThreadId);
  }
  public long getId() {
    return id.incrementAndGet();
  }
}

单例模式和静态方法

单例模式是一种设计模式，也是一种类，一种抽象出的对象。
静态方法也是依附于一个类的，会在类被加载时，构造方法执行之前初始化静态方法，静态方法初始化后和当前的进程生命周期一致的。
补充一些静态方法的内存存储：

在JDK8之前，静态成员（静态变量和静态方法）都是存储在方法区（永久代）中的静态区中（这里指类被加载后，静态成员的存储位置）。但在JDK8之后，永久代被移除了，取而代之的是元空间（metaspace）。但元空间中存储的主要是.class文件的元数据信息，静态成员的存储位置由方法区转到了堆内存（heap）中。
不过，不管是JDK8，还是更早的版本中，静态方法的执行（不仅仅是静态方法，还有普通的成员方法）都是在栈内存（stack）中进行的。每个线程都会在栈内存中开辟一个栈，在调用方法时，对应的方法都会在执行这个方法的线程的栈中创建一个“栈帧”，栈帧中保存了局部变量表（基本数据类型和对象引用）、操作数栈、动态连接和返回地址等信息。等到方法执行完毕，栈帧被销毁，对应的内存也将被释放。