设计模式之单例设计模式---Singleton Design Pattern

定义

如果一个类只允许创建一个对象（实例），那么，这个类就是一个单例类，这种设计模式就是单例设计模式（Singleton Design Pattern）。

从业务概念方面来讲，如果某个类包含的数据在系统中就保存一份，那么这个类应该被设计为单例类。例如配置信息类，在系统中，只因该有一个配置文件，当配置文件被加载到内存之后，以对象的形式存在，也理应只有一份。又例如唯一递增的ID生成器类，如果系统中存在两个ID生成器对象，那么有可能生成重复ID。

单例模式的实现方案

在实现单例模式的时候关注点有4个

1. 构造函数必须具有private访问权限，这样才能避免通过关键字new来创建对象。
2. 对象创建时的线程安全问题
3. 是否支持延迟加载
4. getInstance()函数的性能是否足够高

“饿汉”式

“饿汉”式的实现方式比较简单，在加载类的时候instance就已经被创建初始化，因此，instance实例的创建是线程安全的。不过，这种实现方式不支持延迟加载，instance实例是提前创建好的，并非在使用时再创建。以一个ID生成器为例，其大致的设计如下：

public class IdGenerator{

    private AtomicLong id = new AtomicLong(0);
    private static final IdGenerator instance = new IdGenerator();
    
    private IdGenerator(){}

    public static IdGenerator getInstance(){
        return instance;
    }
    
    public long getId(){
        
        return id.incrementAndGet()
    }
}

"懒汉“式

相对于”饿汉“式，”懒汉“式支持延迟加载，实例创建和初始化推迟到使用时才进行。大致的设计如下：

public class IdGenerator{
    
    private AtomicLong id = new AtomicLong(0);
    
    private static IdGenerator instance;
    private IdGenerator(){}
    
    public static synchronized idGenerator getInstance(){
        
        if(instance == null)
            instance = new idGenerator();
        return instance;
    }
    
    public long getId(){
        
        return id.incrementAndGet();
    }
}

部分人认为”懒汉“式支持延迟加载，比”懒汉“式更合理。理由是：如果实例占用的资源较多（如内存较多）或初始化时间较长（如需要加载各种配置文件），那么提前创建和初始化实例是一种浪费资源的行为。

但是如果初始化的时间较长的化，等到使用的时候再去实例化初始化，那么会影响系统的性能。就比如在执行某个客户端接口请求时，执行初始化操作，会导致接口请求的响应时间变长，甚至超时。但是如果采用”饿汉“式，即在程序启动时提前完成，那么程序运行超时，就能避免再去执行初始化操作而导致的性能问题。

因此如果实例占用的资源多，我们应该才用有问题早暴露的思想即fail-fast。即在启动时就将实例的初始化完成。如果启动时的资源不够，程序启动时就会发生报错，那么我们就能立即处理修复。避免运行时报错，不影响系统的可用性。

与此同时呢”懒汉"式，还有一个明显的缺点，就以上面的代码为例，我们给getInstance（）函数添加了“锁”-------synchronized。这会导致这个函数的并发度为1，也就是说同一时间就允许一个线程执行getInstance()函数。一般来说用到了IdGenerator类就会用到这个函数，如果这个类只是偶尔被用到那么这种方式还是可以接受的，但是如果其被频繁的使用，频繁的加锁、释放锁，会导致并发度低，产生性能瓶颈，这种方式就不太可取，这个时候可以考虑考虑”饿汉“式咯。

双重检测

“饿汉”不支持延迟加载，“懒汉”不支持高并发，那么有没有一种方式即支持延迟加载又支持高并发的单例模式的实现方式呢？双重检测就能满足这样的需求。在这种实现方式中，只要在实例被创建后，再调用getInstance()函数，就不会进入加锁逻辑。因此这种方式就解决了“懒汉”式的并发度低的问题了。大致的设计如下·：

public class IdGenerator{
    
    private AtomicLong id = new AtomicLong();
    
    private static IdGenerator instance;
    
    private IdGenerator(){}
    
    public static IdGenerator getInstance(){
        
        if(instance == null){
            synchronized(IdGenerator.class){ //类级锁
                if(instance == null)
                    instance = new IdGenerator();
                }
            }
        
        return instance;
    }
    
    public long getId(){
    
        return id.incrementAndGet();
    }
}

这种设计模式吧，其实也存在一些问题。按照上面的设计方式：CPU指令重排可能导致IdGenerator类的对象被关键字new创建并赋值给instance之后，还没来的及初始化（执行构造函数中的代码逻辑），就被另一个线程使用了。这样的话另一个线程就使用了一个没有完整初始化的IdGenerator类的对象。解决这个问题也很简单，我们给instance成员变量再添加一个volatile关键字来禁止指令重排。

静态内部类

还有一种比双重检测还要简单的实现方式，那就是利用java的静态内部类实现单例模式。它类似于“饿汉”式，但是能够满足延迟加载。大致的设计如下：

public class IdGenerator{
    
    private AtomicLong id = new AtomicLong();
    
    
    private IdGenerator(){}

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

在上述代码中，SingletonHolder是一个静态内部类，当外部类IdGenerator被加载时，并不会加载SingletonHolder类。只当getInstance()函数第一次被调用时，SingletonHolder类才不会被加载，才会创建出intance。instance的唯一性和创建过程的线程安全性都由JVM保证。因此这种实现方式即保证了线程安全，又能够做到延迟加载。

枚举

最后介绍的实现方式是基于枚举的实现方式。这种方式通过利用Java中枚举的特性而实现。保证了创建线程的安全性和实例的唯一性。大致设计如下：

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

单例设计模式的弊端

单例设计模式隐藏类之间的依赖关系

单例类不需要显示创建，不需要依赖参数传递，在函数中直接调用即可，这种依赖关系隐蔽。因此在阅读代码的时候需要仔细地看每个函数地代码，才能知道这个类依赖了哪些单例类。

单例模式影响了代码地扩展性

 单例类只能创建一个实例，如果有一天我们想要创建两个或者多个的话，就要对代码进行大量的改动。这是我们所不想遇到的。

单例模式影响代码的可测试性

如果单例类依赖外部资源，如数据库，那么在编写单元测试时，我们希望通过Mock方式将他替换掉。但是下面这段代码所示的类似硬编码的使用方式，显然无法实现mock替换。

public class Order{
    
    public void create(...){
        ...
        long id = IdGenerator.getInstance().getId();
        ...
    }
}

此外，如果单例类持有成员变量（如IdGenerator类中的成员变量id），那么实际上相当于全局变量，被所有的代码共享。如果此成员变量时可以被修改的，那么，在编写单元测试时，想要注意不同的测试用例之间，如果修改了单例类中的同一个成员变量的值，那么会导致测试结果互相影响。

单例模式不支持包含参数构造函数

由于单例模式不支持包含参数的构造函数，因此要创建一个连接池的单例对象，无法定义连接池的大小，这种问题我们给出三种解决方式；

1）通过init（）函数传递参数。在调用getInstance()之前调用init()，否则抛出异常。

public class Singleton{
    
private int paramA;
private int paramB;
private static Singleton instance = null;

private Singleton(int paramA , int paramB){
    this.paramA = paramA;
    this.paramB = paramB;
}

public static Singleton getInstance(){
    if(instance == null)
        throw new RuntimeException("Run init() first.");
    return instance;
}

public sychronized static Singleton init(int paramA , int paramB){

    if(instance != null)
        throw new RuntimeException("Singleton has been created!");
    instance = new Singleton(paramA , paramB);
    return instance;
}

}

2) 将参数放到getInstance()函数中。

public class Singleton{
    
private int paramA;
private int paramB;
private static Singleton instance = null;

private Singleton(int paramA , int paramB){
    this.paramA = paramA;
    this.paramB = paramB;
}

public static Singleton getInstance(int paramA , int paramB){
    if(instance == null)
        instance = new Singleton(paramA , paramB);
    return instance;
}

}

这种参数传递的方式并不优雅，如果第一次调用传递的方式和第二次的不同只有第一次的会生效，第二次的实际上不会生效，这就误导了使用者。

2）将参数放到全局变量中，就如下所示，Config类被定义成了存储paramA和paramB的全局变量。这样参数既能像以下代码所示那样，通过静态常量定义，又可以从配置文件中加载得到。这种相对于前面两个是值得推介的。

public class Config{
    public static final int PARAM_A = 123;
    public static final int PARAM_B = 245;
}

public class Singleton{
    
    private static Singleton instance = null;
    private final int paramA;
    private final int paramB;
    
    private Singleton(){
        
        this.paramA = Config.PARAM_A;
        this.paramB = Config.PARAM_B;
    }
    
    public synchronized static Singleton getInstance(){
        if(instance == null)
            instance = new Singleton();
        return instance;
    }
}