【设计模式 | JAVA】之 单例模式

本文源码已收录GIT：Design-Pattern

为了节省内存资源、保证数据内容的一致性，对某些类要求只能创建一个实例，这就是所谓的单例模式。单例模式可以避免一个全局使用的类被频繁地创建和销毁。

单例模式的定义与特点

单例（Singleton）模式的定义：指一个类只有一个实例，且该类能自行创建这个实例的一种模式。

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

特点：

1. 单例类只有一个实例对象；
2. 该单例对象必须由单例类自行创建；
3. 单例类对外提供一个访问该单例的全局访问点；

单例模式需要将构造函数私有化(避免外部使用构造函数创建对象)，并为单例对象提供一个全局的访问点。

意图：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

主要解决：

一个全局使用的类频繁地创建与销毁。

何时使用：

当想控制实例数目，节省系统资源的时候。

如何解决：

判断系统是否已经有这个单例，如果有则返回，如果没有则创建。

关键代码：

构造函数是私有的。

优点：

• 1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如首页页面缓存）。
• 2、避免对资源的多重占用（比如写文件操作）。

缺点：

没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

使用场景：

• 1、要求生产唯一序列号。
• 2、WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。
• 3、创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。

注意事项：getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化。

单例模式的结构与实现

单例模式是设计模式中最简单的模式之一。通常，普通类的构造函数是公有的，外部类可以通过“new 构造函数()”来生成多个实例。但是，如果将类的构造函数设为私有的，外部类就无法调用该构造函数，也就无法生成多个实例。这时该类自身必须定义一个静态私有实例，并向外提供一个静态的公有函数用于创建或获取该静态私有实例。

下面来分析其基本结构和实现方法。

1. 单例模式的结构

单例模式的主要角色如下。

• 单例类：包含一个实例且能自行创建这个实例的类。
• 访问类：使用单例的类。

其结构如图所示。

2. 单例模式的实现

Singleton 模式通常有两种实现形式。

第 1 种：懒汉式单例

该模式的特点是类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例。

#1 懒汉式，线程不安全

是否 Lazy 初始化：是

是否多线程安全：否

实现难度：易

描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。
这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。

public class Singleton {  
    //声明一个私有的对象引用。private保护其不被直接访问修改,static保护本类唯一
    private static Singleton instance;  
    //构造函数私有化。private 避免类在外部被实例化
    private Singleton (){}  
    //获得单例实例的静态方法作外部访问点
    //用synchronized修饰为同步,确保多线程环境下只创建这一个对象
    public static Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
    return instance;  
    }  
}

#2 懒汉式，线程安全

是否 Lazy 初始化：是

是否多线程安全：是

实现难度：易

描述：这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
优点：第一次调用才初始化，避免内存浪费。
缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。
getInstance() 的性能对应用程序不是很关键（该方法使用不太频繁）。

public class LazySingleton {
    //保证 instance 在所有线程中同步
    private static volatile LazySingleton instance = null;
    //private 避免类在外部被实例化
    private LazySingleton(){}

    public static synchronized LazySingleton getInstance(){
        //getInstance 方法前加同步
        if (instance == null) {
            instance = new LazySingleton();
        }
        return instance;
    }
}

注意：如果编写的是多线程程序，则不要删除上例代码中的关键字 volatile 和 synchronized，否则将存在线程非安全的问题。如果不删除这两个关键字就能保证线程安全，但是每次访问时都要同步，会影响性能，且消耗更多的资源，这是懒汉式单例的缺点。

第 2 种：饿汉式单例

该模式的特点是类一旦加载就创建一个单例，保证在调用 getInstance 方法之前单例已经存在了。

是否 Lazy 初始化：否

是否多线程安全：是

实现难度：易

描述：这种方式比较常用，但容易产生垃圾对象。
优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。
它基于 classloader 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。

public class HungrySingleton {
    //这里的final主要用来限制变量不允许修改，即instance变量赋值后就不再改变
    private static final HungrySingleton instance = new HungrySingleton();
    
    private HungrySingleton(){}

    public static HungrySingleton getInstance(){
        return instance;
    }

}

对于final修饰的测试请参考：饿汉单例模式一定要加final？

第 3 种：双检锁/双重校验锁

（DCL，即 double-checked locking）

JDK 版本：JDK1.5 起

是否 Lazy 初始化：是

是否多线程安全：是

实现难度：较复杂

描述：这种方式采用双锁机制，安全且在多线程情况下能保持高性能。
getInstance() 的性能对应用程序很关键。

public class DoubleCheckedSingleton {
    private static volatile DoubleCheckedSingleton instance;
    
    private DoubleCheckedSingleton(){}

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

 第 4 种：静态内部类

是否 Lazy 初始化：是

是否多线程安全：是

实现难度：一般

优点：

1.采用静态内部类的方式，作为单例，直接用classLoader（jvm类加载机制）进行处理异步加锁问题，并减少内存消耗

2.懒加载(饿汉式），即延迟加载。

3.线程安全。

描述：这种方式能达到双检锁方式一样的功效，但实现更简单。对静态域使用延迟初始化，应使用这种方式而不是双检锁方式。这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。

public class InnerClassSingleton {
    //静态内部类
    private static class SingletonHolder{
        //静态初始化器机制初始化本数据（保证了同步控制，线程安全）
        private static InnerClassSingleton instance = new InnerClassSingleton();
    }
    //私有构造方法
    private InnerClassSingleton(){}
    //获得对象实例
    public static InnerClassSingleton getInstance(){
        return SingletonHolder.instance;
    }
}

这种方式同样利用了 classloader 机制来保证初始化 instance 时只有一个线程，它跟第 2 种方式不同的是：第 2 种方式只要 Singleton 类被装载了，那么 instance 就会被实例化（没有达到 lazy loading 效果），而这种方式是 Singleton 类被装载了，instance 不一定被初始化。因为 SingletonHolder 类没有被主动使用，只有通过显式调用 getInstance 方法时，才会显式装载 SingletonHolder 类，从而实例化 instance。想象一下，如果实例化 instance 很消耗资源，所以想让它延迟加载，另外一方面，又不希望在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的。这个时候，这种方式相比第 2 种方式就显得很合理。

第 5 种：登记式

是否 Lazy 初始化：是

是否多线程安全：是

实现难度：一般

优点：

1.将非单例的类，进行登记管理，变为单列

2.懒加载(饿汉式），即延迟加载。

3.线程安全。

描述：登记式实际对一组单例模式进行的维护，主要是在数量上的扩展，通过map我们把单例存进去，这样在调用时，先判断该单例是否已经创建，是的话直接返回，不是的话创建一个登记到map中，再返回。

可以单独设置一个类来管理要登记的单例对象，也可以为单例对象类自己设置登记容器。

#1 单独类管理要登记的单例对象

public class ManagerSingleton {
    //线程安全的容器,饿汉式保证容器对象本身为单例
    private static Map<String,Object> MANAGER = new ConcurrentHashMap();
    //外部访问点,传入类名,返回该类的单例对象.该类会被登记进入上面的容器进行单例管理
    //在类中务必保证构造方法私有化,对这一点这个管理类是无法控制的,需要自己保证
    public static Object getInstance(String className) {
        //如果还没登记到容器
        if (!MANAGER.containsKey(className)) {
            //用反射的方式创建对象(因为已经构造函数私有化),并登记到容器中
            try {
                MANAGER.put(className, Class.forName(className).newInstance());
            } catch (InstantiationException e) {
                e.printStackTrace();
            } catch (IllegalAccessException e) {
                e.printStackTrace();
            } catch (ClassNotFoundException e) {
                e.printStackTrace();
            }
        }
        //从容器中获取管理的单例对象并返回
        return MANAGER.get(className);
    }
}

#2 单例对象类设置登记容器

public class RegisterSingleton {
    //用ConcurrentHashMap来维护映射关系，线程安全
    private static final Map<String,Object> REGISTER = new ConcurrentHashMap<>();
    static {
        //把RegisterSingleton自己也纳入容器管理
        RegisterSingleton registerSingleton = new RegisterSingleton();
        REGISTER.put(registerSingleton.getClass().getName(),registerSingleton);
    }
    //构造方法私有化
    private RegisterSingleton(){}
    public static Object getInstance(String className){
        //如果传入的类名为空，就返回RegisterSingleton实例
        if (className == null) {
            className = RegisterSingleton.class.getName();
        }
        //如果没有登记就用反射实例化
        if (!REGISTER.containsKey(className)) {
            //没有登记就进入同步块
            synchronized (RegisterSingleton.class){
                //再次检测是否登记
                if (!REGISTER.containsKey(className)) {
                    try {
                        //反射，实例化对象
                        REGISTER.put(className,Class.forName(className).newInstance());
                    } catch (InstantiationException e) {
                        e.printStackTrace();
                    } catch (IllegalAccessException e) {
                        e.printStackTrace();
                    } catch (ClassNotFoundException e) {
                        e.printStackTrace();
                    }
                }
            }
        }
        //返回单例
        return REGISTER.get(className);
    }
}

第 6 种：枚举

JDK 版本：JDK1.5 起

是否 Lazy 初始化：否

是否多线程安全：是

实现难度：易

描述：这种实现方式还没有被广泛采用，但这是实现单例模式的最佳方法。它更简洁，自动支持序列化机制，绝对防止多次实例化。
这种方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，绝对防止多次实例化。不过，由于 JDK1.5 之后才加入 enum 特性，用这种方式写不免让人感觉生疏，在实际工作中，也很少用。
不能通过 reflection attack 来调用私有构造方法。

public enum EnumSingleton {
    INSTANCE;
    public void whateverMethod() {
    }
}

枚举的构造函数本身就是私有的，而且可以自由序列化、线程安全、保证单例。使用枚举是实现单例模式的最佳方式。以前对枚举不太了解，实际上枚举就是一个final类，也一样可以有其它属性和方法，当成普通类来用实现单例极为简便。

经验之谈：一般情况下，不建议使用懒汉方式，建议使用饿汉方式。只有在要明确实现 lazy loading 效果时，才会使用登记方式。如果涉及到反序列化创建对象时，可以尝试使用枚举方式。如果有其他特殊的需求，可以考虑使用双检锁方式。

单例模式的应用场景

前面分析了单例模式的结构与特点，以下是它通常适用的场景的特点。

• 在应用场景中，某类只要求生成一个对象的时候，如一个班中的班长、每个人的身份证号等。
• 当对象需要被共享的场合。由于单例模式只允许创建一个对象，共享该对象可以节省内存，并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。
• 当某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。

单例模式的扩展

单例模式可扩展为有限的多例（Multitcm）模式，这种模式可生成有限个实例并保存在 ArmyList 中，客户需要时可随机获取，其结构图如图  所示。
 

本文源码已收录GIT：Design-Pattern