大话设计模式-----单例模式

最新推荐文章于 2021-06-21 17:03:28 发布

天--空

最新推荐文章于 2021-06-21 17:03:28 发布

阅读量148

点赞数

本文借鉴博客https://blog.csdn.net/justloveyou_/article/details/64127789

1、定义

保证一个类仅有一个实例（静态的），并提供一个访问它的全局访问点(getInstance())。

2、理解

国家虽然规定了只能生一个小孩的规定，但实际上你要生几个小孩，是你自己说了算，而不是国家说了算。同样，对于一个类，要有几个实例是这个类本身说了算，而不是其他的类说了算（例如在main方法中）。单例模式因为Singleton类封装它的唯一实例，这样它可以严格的控制客户怎样访问它以及何时访问它。简单说就是对唯一实例的受控访问（例如只能通过getInstance（）方法去访问）。许多时候，整个系统只需要拥有一个的全局对象，这样有利于我们协调系统整体的行为。比如在某个服务器程序中，该服务器的配置信息存放在一个文件中，这些配置数据由一个单例对象统一读取，然后服务进程中的其他对象再通过这个单例对象获取这些配置信息，显然，这种方式简化了在复杂环境下的配置管理。还有选择单例模式可以避免不一致状态，例如，每台计算机可以有若干个打印机，但只能有一个 Printer Spooler (单例) ，以避免两个打印作业同时输出到打印机中。

3、实现

（1）单线程环境下的两种经典实现

在介绍单线程环境中单例模式的两种经典实现之前，我们有必要先解释一下立即加载和延迟加载两个概念。

立即加载：在类加载初始化的时候就主动创建实例；
延迟加载：等到真正使用的时候才去创建实例，不用时不去主动创建。

在单线程环境下，单例模式根据实例化对象时机的不同，有两种经典的实现：一种是饿汉式单例(立即加载)，一种是懒汉式单例(延迟加载)。饿汉式单例在单例类被加载时候，就实例化一个对象并交给自己的引用；而懒汉式单例只有在真正使用的时候才会实例化一个对象并交给自己的引用。代码示例分别如下：

饿汉式单例：

// 饿汉式单例
public class Singleton1 {

    // 指向自己实例的私有静态引用，主动创建
    private static Singleton1 singleton1 = new Singleton1();

    // 私有的构造方法
    private Singleton1(){}

    // 以自己实例为返回值的静态的公有方法，静态工厂方法
    public static Singleton1 getSingleton1(){
        return singleton1;
    }
}

我们知道，类加载的方式是按需加载，且加载一次。因此，在上述单例类被加载时，就会实例化一个对象并交给自己的引用，供系统使用；而且，由于这个类在整个生命周期中只会被加载一次，因此只会创建一个实例，即能够充分保证单例。

懒汉式单例：

// 懒汉式单例
public class Singleton2 {

    // 指向自己实例的私有静态引用
    private static Singleton2 singleton2;

    // 私有的构造方法
    private Singleton2(){}

    // 以自己实例为返回值的静态的公有方法，静态工厂方法
    public static Singleton2 getSingleton2(){
        // 被动创建，在真正需要使用时才去创建
        if (singleton2 == null) {
            singleton2 = new Singleton2();
        }
        return singleton2;
    }
}

我们从懒汉式单例可以看到，单例实例被延迟加载，即只有在真正使用的时候才会实例化一个对象并交给自己的引用。

总之，从速度和反应时间角度来讲，饿汉式（又称立即加载）要好一些；从资源利用效率上说，懒汉式（又称延迟加载）要好一些。

（2）单例模式在多线程下的实现

在单线程环境下，无论是饿汉式单例还是懒汉式单例，它们都能够正常工作。但是，在多线程环境下，情形就发生了变化：由于饿汉式单例天生就是线程安全的，可以直接用于多线程而不会出现问题；但懒汉式单例本身是非线程安全的，因此就会出现多个实例的情况，与单例模式的初衷是相背离的。下面我重点阐述以下几个问题：

为什么说饿汉式单例天生就是线程安全的？
传统的懒汉式单例为什么是非线程安全的？
怎么修改传统的懒汉式单例，使其线程变得安全？
线程安全的单例的实现还有哪些，怎么实现？
双重检查模式、Volatile关键字在单例模式中的应用
ThreadLocal 在单例模式中的应用

特别地，为了能够更好的观察到单例模式的实现是否是线程安全的，我们提供了一个简单的测试程序来验证。该示例程序的判断原理是：

　　开启多个线程来分别获取单例，然后打印它们所获取到的单例的hashCode值。若它们获取的单例是相同的(该单例模式的实现是线程安全的)，那么它们的hashCode值一定完全一致；若它们的hashCode值不完全一致，那么获取的单例必定不是同一个，即该单例模式的实现不是线程安全的，是多例的。注意，相应输出结果附在每个单例模式实现示例后。

public class Test {
    public static void main(String[] args) {
        Thread[] threads = new Thread[10];
        for (int i = 0; i < threads.length; i++) {
            threads[i] = new TestThread();
        }

        for (int i = 0; i < threads.length; i++) {
            threads[i].start();
        }
    }

}

class TestThread extends Thread {
    @Override
    public void run() {
        // 对于不同单例模式的实现，只需更改相应的单例类名及其公有静态工厂方法名即可
        int hash = Singleton5.getSingleton5().hashCode();  
        System.out.println(hash);
    }
}

I、为什么说饿汉式单例天生就是线程安全的？

// 饿汉式单例
public class Singleton1 {

    // 指向自己实例的私有静态引用，主动创建
    private static Singleton1 singleton1 = new Singleton1();

    // 私有的构造方法
    private Singleton1(){}

    // 以自己实例为返回值的静态的公有方法，静态工厂方法
    public static Singleton1 getSingleton1(){
        return singleton1;
    }
}/* Output(完全一致): 
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
 *///:~

类加载只加载一次。因此，在上述单例类被加载时，就会实例化一个对象并交给自己的引用，供系统使用。换句话说，在线程访问单例对象之前就已经创建好了。再加上，由于一个类在整个生命周期中只会被加载一次，因此该单例类只会创建一个实例，也就是说，线程每次都只能也必定只可以拿到这个唯一的对象。因此就说，饿汉式单例天生就是线程安全的。

II、传统的懒汉式单例为什么是非线程安全的？

// 传统懒汉式单例
public class Singleton2 {

    // 指向自己实例的私有静态引用
    private static Singleton2 singleton2;

    // 私有的构造方法
    private Singleton2(){}

    // 以自己实例为返回值的静态的公有方法，静态工厂方法
    public static Singleton2 getSingleton2(){
        // 被动创建，在真正需要使用时才去创建
        if (singleton2 == null) {
            singleton2 = new Singleton2();
        }
        return singleton2;
    }
}/* Output(不完全一致): 
        1084284121
        2136955031
        2136955031
        1104499981
        298825033
        298825033
        2136955031
        482535999
        298825033
        2136955031
 *///:~

上面发生非线程安全的一个显著原因是，会有多个线程同时进入 if (singleton2 == null) {…} 语句块的情形发生。当这种这种情形发生后，该单例类就会创建出多个实例，违背单例模式的初衷。因此，传统的懒汉式单例是非线程安全的。

III、实现线程安全的懒汉式单例的几种正确姿势

1)、同步延迟加载 — synchronized方法

// 线程安全的懒汉式单例
public class Singleton2 {

    private static Singleton2 singleton2;

    private Singleton2(){}

    // 使用 synchronized 修饰，临界资源的同步互斥访问
    public static synchronized Singleton2 getSingleton2(){
        if (singleton2 == null) {
            singleton2 = new Singleton2();
        }
        return singleton2;
    }
}/* Output(完全一致): 
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
 *///:~

该实现与上面传统懒汉式单例的实现唯一的差别就在于：是否使用 synchronized 修饰 getSingleton2()方法。若使用，就保证了对临界资源的同步互斥访问，也就保证了单例。

从执行结果上来看，问题已经解决了，但是这种实现方式的运行效率会很低，因为同步块的作用域有点大，而且锁的粒度有点粗。同步方法效率低，那我们考虑使用同步代码块来实现。

2)、同步延迟加载 — synchronized块

// 线程安全的懒汉式单例
public class Singleton2 {

    private static Singleton2 singleton2;

    private Singleton2(){}


    public static Singleton2 getSingleton2(){
        synchronized(Singleton2.class){  // 使用 synchronized 块，临界资源的同步互斥访问
            if (singleton2 == null) { 
                singleton2 = new Singleton2();
            }
        }
        return singleton2;
    }
}/* Output(完全一致): 
        16993205
        16993205
        16993205
        16993205
        16993205
        16993205
        16993205
        16993205
        16993205
        16993205
 *///:~

该实现与上面synchronized方法版本实现类似，此不赘述。从执行结果上来看，问题已经解决了，但是这种实现方式的运行效率仍然比较低，事实上，和使用synchronized方法的版本相比，基本没有任何效率上的提高。

3)、同步延迟加载 — 使用内部类实现延迟加载

// 线程安全的懒汉式单例
public class Singleton5 {

    // 私有内部类，按需加载，用时加载，也就是延迟加载
    private static class Holder {
        private static Singleton5 singleton5 = new Singleton5();
    }

    private Singleton5() {

    }

    public static Singleton5 getSingleton5() {
        return Holder.singleton5;
    }
}
/* Output(完全一致): 
        482535999
        482535999
        482535999
        482535999
        482535999
        482535999
        482535999
        482535999
        482535999
        482535999
 *///:~

如上述代码所示，我们可以使用内部类实现线程安全的懒汉式单例，这种方式也是一种效率比较高的做法，它与饿汉式单例的区别就是：这种方式不但是线程安全的，还是延迟加载的，真正做到了用时才初始化。

　　当客户端调用getSingleton5()方法时，会触发Holder类的初始化。由于singleton5是Hold的类成员变量，因此在JVM调用Holder类的类构造器对其进行初始化时，虚拟机会保证一个类的类构造器在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的类构造器，其他线程都需要阻塞等待，直到活动线程执行方法完毕。在这种情形下，其他线程虽然会被阻塞，但如果执行类构造器方法的那条线程退出后，其他线程在唤醒之后不会再次进入/执行类构造器，因为在同一个类加载器下，一个类型只会被初始化一次，因此就保证了单例。

4）同步延迟加载 — 双重检查机制

使用双重检测同步延迟加载去创建单例的做法是一个非常优秀的做法，其不但保证了单例，而且切实提高了程序运行效率，对应的代码清单如下

// 线程安全的懒汉式单例
public class Singleton3 {

    //使用volatile关键字防止重排序，因为 new Instance()是一个非原子操作，可能创建一个不完整的实例
    private static volatile Singleton3 singleton3;

    private Singleton3() {
    }

    public static Singleton3 getSingleton3() {
        // Double-Check idiom
        if (singleton3 == null) {
            synchronized (Singleton3.class) {       // 1
                // 只需在第一次创建实例时才同步
                if (singleton3 == null) {       // 2
                    singleton3 = new Singleton3();      // 3
                }
            }
        }
        return singleton3;
    }
}/* Output(完全一致): 
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
        1104499981
 *///:~

　　如上述代码所示，为了在保证单例的前提下提高运行效率，我们需要对 singleton3 进行第二次检查，目的是避开过多的同步（因为这里的同步只需在第一次创建实例时才同步，一旦创建成功，以后获取实例时就不需要同步获取锁了）。这种做法无疑是优秀的，但是我们必须注意一点：必须使用volatile关键字修饰单例引用。

那么，如果上述的实现没有使用 volatile 修饰 singleton3，会导致什么情形发生呢？为解释该问题，我们分两步来阐述：

one、当我们写了 new 操作，JVM 到底会发生什么？

　　首先，我们要明白的是： new Singleton3() 是一个非原子操作。代码行singleton3 = new Singleton3(); 的执行过程可以形象地用如下3行伪代码来表示：

memory = allocate();        //1:分配对象的内存空间
ctorInstance(memory);       //2:初始化对象
singleton3 = memory;        //3:使singleton3指向刚分配的内存地址

　　但实际上，这个过程可能发生无序写入(指令重排序)，也就是说上面的3行指令可能会被重排序导致先执行第3行后执行第2行，也就是说其真实执行顺序可能是下面这种：

memory = allocate();        //1:分配对象的内存空间
singleton3 = memory;        //3:使singleton3指向刚分配的内存地址
ctorInstance(memory);       //2:初始化对象

　　这段伪代码演示的情况不仅是可能的，而且是一些 JIT 编译器(热点编译器）上真实发生的现象。

two、重排序情景再现
　　
　　了解 new 操作是非原子的并且可能发生重排序这一事实后，我们回过头看使用 Double-Check idiom 的同步延迟加载的实现：

　　我们需要重新考察上述清单中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 singleton3 来引用此对象。这行代码存在的问题是，在 Singleton 构造函数体执行之前，变量 singleton3 可能提前成为非 null 的，即赋值语句在对象实例化之前调用，此时别的线程将得到的是一个不完整（未初始化）的对象，会导致系统崩溃。下面是程序可能的一组执行步骤：

　　1、线程 1 进入 getSingleton3() 方法；
　　2、由于 singleton3 为 null，线程 1 在 //1 处进入 synchronized 块；
　　3、同样由于 singleton3 为 null，线程 1 直接前进到 //3 处，但在构造函数执行之前，使实例成为非 null，并且该实例是未初始化的；
　　4、线程 1 被线程 2 预占；
　　5、线程 2 检查实例是否为 null。因为实例不为 null，线程 2 得到一个不完整（未初始化）的 Singleton 对象；
　　6、线程 2 被线程 1 预占。
　　7、线程 1 通过运行 Singleton3 对象的构造函数来完成对该对象的初始化。

　　显然，一旦我们的程序在执行过程中发生了上述情形，就会造成灾难性的后果，而这种安全隐患正是由于指令重排序的问题所导致的。让人兴奋地是，volatile 关键字正好可以完美解决了这个问题。也就是说，我们只需使用volatile关键字修饰单例引用就可以避免上述灾难。

5）单例模式与ThreadLocal

借助于 ThreadLocal，我们可以实现双重检查模式的变体。我们将临界资源instance线程私有化(局部化)，具体到本例就是将双重检测的第一层检测条件 if (instance == null) 转换为线程局部范围内的操作，对应的代码清单如下：

public class Singleton {

    // ThreadLocal 线程局部变量，将单例instance线程私有化
    private static ThreadLocal<Singleton> threadlocal = new ThreadLocal<Singleton>();
    private static Singleton instance;

    private Singleton() {

    }

    public static Singleton getInstance() {

        // 第一次检查：若线程第一次访问，则进入if语句块；否则，若线程已经访问过，则直接返回ThreadLocal中的值
        if (threadlocal.get() == null) {
            synchronized (Singleton.class) {
                if (instance == null) {  // 第二次检查：该单例是否被创建
                    instance = new Singleton();
                }
            }
            threadlocal.set(instance); // 将单例放入ThreadLocal中
        }
        return threadlocal.get();
    }
}/* Output(完全一致): 
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
        1028355155
*///:~

　　借助于 ThreadLocal，我们也可以实现线程安全的懒汉式单例。但与直接使用双重检查模式，本实现在效率上还不如后者。

5、结构图

　特别地，为了更好地理解上面的类图，我们以此为契机，介绍一下类图的几个知识点：

类图分为三部分，依次是类名、属性、方法；
以<<开头和以>>结尾的为注释信息；
修饰符+代表public，-代表private，#代表protected，什么都没有代表包可见；
带下划线的属性或方法代表是静态的。

三要素：

私有的构造方法；
指向自己实例的私有静态引用；
以自己实例为返回值的静态的公有方法。

6、单例模式的优点

　　我们从单例模式的定义和实现，可以知道单例模式具有以下几个优点：

在内存中只有一个对象，节省内存空间；
避免频繁的创建销毁对象，可以提高性能；
避免对共享资源的多重占用，简化访问；
为整个系统提供一个全局访问点。

7、单例模式应用场景

由于单例模式具有以上优点，并且形式上比较简单，所以是日常开发中用的比较多的一种设计模式，其核心在于为整个系统提供一个唯一的实例，其应用场景包括但不仅限于以下几种：

有状态的工具类对象；
频繁访问数据库或文件的对象；

8、单例模式的注意事项　　

在使用单例模式时，我们必须使用单例类提供的公有工厂方法得到单例对象，而不应该使用反射来创建，否则将会实例化一个新对象。此外，在多线程环境下使用单例模式时，应特别注意线程安全问题。

9、总结

本文首先介绍了单例模式的定义和结构，并给出了其在单线程和多线程环境下的几种经典实现。特别地，我们知道，传统的饿汉式单例无论在单线程还是多线程环境下都是线程安全的，但是传统的懒汉式单例在多线程环境下是非线程安全的。为此，我们特别介绍了五种方式来在多线程环境下创建线程安全的单例，包括：

使用synchronized方法实现懒汉式单例；
使用synchronized块实现懒汉式单例；
使用静态内部类实现懒汉式单例；
使用双重检查模式实现懒汉式单例；
使用ThreadLocal实现懒汉式单例；

　　当然，实现懒汉式单例还有其他方式。但是，这五种是比较经典的实现，也是我们应该掌握的几种实现方式。从这五种实现中，我们可以总结出，要想实现效率高的线程安全的单例，我们必须注意以下两点：

尽量减少同步块的作用域；
尽量使用细粒度的锁。

天--空

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
大话设计模式-----单例模式

本文借鉴博客https://blog.csdn.net/justloveyou_/article/details/641277891、定义保证一个类仅有一个实例（静态的），并提供一个访问它的全局访问点(getInstance())。2、理解国家虽然规定了只能生一个小孩的规定，但实际上你要生几个小孩，是你自己说了算，而不是国家说了算。同样，对于一个类，要有几个实例是这个类本身说了算，...
复制链接

扫一扫