单例模式总结

时间 2019-12-06

标签模式总结繁體版

原文原文链接

第一种（懒汉, 线程不安全）：java

public class Singleton {
    private static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

这种写法 lazy loading 很明显, 可是致命的是在多线程不能正常工做。缓存

第二种（懒汉, 线程安全）：安全

public class Singleton {
    private static Singleton instance;

    private Singleton() {
    }

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

这种写法可以在多线程中很好的工做, 并且看起来它也具有很好的 lazy loading, 可是, 遗憾的是, 效率很低, 99% 状况下不须要同步。多线程

第三种（饿汉）：函数

public class Singleton {
    private static Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }
}

这种方式基于 classloder 机制避免了多线程的同步问题, 不过, instance 在类装载时就实例化, 虽然致使类装载的缘由有不少种, 在单例模式中大多数都是调用 getInstance 方法, 可是也不能肯定有其余的方式（或者其余的静态方法）致使类装载, 这时候初始化 instance 显然没有达到 lazy loading 的效果。优化

第四种（饿汉, 变种）：this

public class Singleton {
    private Singleton instance = null;

    static {
        instance = new Singleton();
    }

    private Singleton() {
    }

    public static Singleton getInstance() {
        return this.instance;
    }
}

表面上看起来差异挺大, 其实更第三种方式差很少, 都是在类初始化即实例化 instance。线程

第五种（静态内部类）：code

public class Singleton {
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    private Singleton() {
    }

    public static final Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

这种方式一样利用了classloder的机制来保证初始化instance时只有一个线程, 它跟第三种和第四种方式不一样的是（很细微的差异）：第三种和第四种方式是只要Singleton类被装载了, 那么instance就会被实例化（没有达到lazy loading效果）, 而这种方式是Singleton类被装载了, instance不必定被初始化。由于SingletonHolder类没有被主动使用, 只有显示经过调用getInstance方法时, 才会显示装载SingletonHolder类, 从而实例化instance。想象一下, 若是实例化instance很消耗资源, 我想让他延迟加载, 另一方面, 我不但愿在Singleton类加载时就实例化, 由于我不能确保Singleton类还可能在其余的地方被主动使用从而被加载, 那么这个时候实例化instance显然是不合适的。这个时候, 这种方式相比第三和第四种方式就显得很合理。对象

第六种（枚举）：

public enum Singleton {
    INSTANCE;

    public void whateverMethod() {
    }
}

这种方式是 Effective Java做者 Josh Bloch 提倡的方式, 它不只能避免多线程同步问题, 并且还能防止反序列化从新建立新的对象, 可谓是很坚强的壁垒啊, 不过, 我的认为因为 1.5 中才加入 enum 特性, 用这种方式写难免让人感受生疏, 在实际工做中, 我也不多看见有人这么写过。

第七种（双重校验锁）：

public class Singleton {
    private volatile static Singleton singleton;

    private Singleton() {
    }

    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

这个是第二种方式的升级版, 俗称双重检查锁定, 也有瑕疵。
主要在于singleton = new Singleton()这句，这并不是是一个原子操做，事实上在 JVM 中这句话大概作了下面 3 件事情。

给 singleton 分配内存
调用 Singleton 的构造函数来初始化成员变量，造成实例
将singleton对象指向分配的内存空间（执行完这步 singleton才是非 null 了）
可是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序多是 1-2-3 也多是 1-3-2。若是是后者，则在 3 执行完毕、2 未执行以前，被线程二抢占了，这时 instance 已是非 null 了（但却没有初始化），因此线程二会直接返回 instance.

在JDK1.5以后, 双重检查锁定才可以正常达到单例效果，1.5以前有个坑。

说这个坑以前咱们要先来看看volatile这个关键字。其实这个关键字有两层语义。第一层语义相信你们都比较熟悉，就是可见性。可见性指的是在一个线程中对该变量的修改会立刻由工做内存（Work Memory）写回主内存（Main Memory），因此会立刻反应在其它线程的读取操做中。顺便一提，工做内存和主内存能够近似理解为实际电脑中的高速缓存和主存，工做内存是线程独享的，主存是线程共享的。volatile的第二层语义是禁止指令重排序优化。你们知道咱们写的代码（尤为是多线程代码），因为编译器优化，在实际执行的时候可能与咱们编写的顺序不一样。编译器只保证程序执行结果与源代码相同，却不保证明际指令的顺序与源代码相同。这在单线程看起来没什么问题，然而一旦引入多线程，这种乱序就可能致使严重问题。volatile关键字就能够从语义上解决这个问题。
可是很不幸，禁止指令重排优化这条语义直到jdk1.5之后才能正确工做。此前的JDK中即便将变量声明为volatile也没法彻底避免重排序所致使的问题。因此，在jdk1.5版本前，双重检查锁形式的单例模式是没法保证线程安全的。

总结

有两个问题须要注意：

若是单例由不一样的类装载器装入, 那便有可能存在多个单例类的实例。假定不是远端存取, 例如一些servlet容器对每一个servlet使用彻底不一样的类装载器, 这样的话若是有两个servlet访问一个单例类, 它们就都会有各自的实例。
若是 Singleton 实现了 java.io.Serializable 接口, 那么这个类的实例就可能被序列化和复原。无论怎样, 若是你序列化一个单例类的对象, 接下来复原多个那个对象, 那你就会有多个单例类的实例。

对第一个问题修复的办法：

private static Class getClass(String classname) throws ClassNotFoundException {
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

        if (classLoader == null) {
            classLoader = Singleton.class.getClassLoader();
        }

        return (classLoader.loadClass(classname));
}

对第二个问题修复的办法：

public class Singleton implements java.io.Serializable {
    public static Singleton INSTANCE = new Singleton();

    protected Singleton() {
    }

    private Object readResolve() {
        return INSTANCE;
    }
}

对我来讲, 我比较喜欢第三种和第五种方式, 简单易懂, 并且在JVM层实现了线程安全（若是不是多个类加载器环境）, 通常的状况下, 我会使用第三种方式, 只有在要明确实现lazy loading效果时才会使用第五种方式, 另外, 若是涉及到反序列化建立对象时我会试着使用枚举的方式来实现单例, 不过, 我一直会保证个人程序是线程安全的, 并且我永远不会使用第一种和第二种方式, 若是有其余特殊的需求, 我可能会使用第七种方式, 毕竟, JDK1.5已经没有双重检查锁定的问题了。
不过通常来讲, 第一种不算单例, 第四种和第三种就是一种, 若是算的话, 第五种也能够分开写了。因此说, 通常单例都是五种写法。懒汉, 恶汉, 双重校验锁, 枚举和静态内部类。

三大要点

线程安全
延迟加载
序列化与反序列化安全

除了枚举形式, 其余实现方式都有两个共同的缺点

都须要额外的工做(Serializable、transient、readResolve())来实现序列化，不然每次反序列化一个序列化的对象实例时都会建立一个新的实例。
可能会有人使用反射强行调用咱们的私有构造器（若是要避免这种状况，能够修改构造器，让它在建立第二个实例的时候抛异常）。