设计模式 - 对象性能之单例模式

面向对象很好地解决了”抽象“的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。

典型模式：Singleton、Flyweight

在软件系统中，经常有这样一些特殊的类，必须保证它们再系统中只存在一个实例，才能确保它们的逻辑正确性，以及良好的效率

如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？

这应该是设计者的责任，而不是使用者的责任

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

Singleton 模式中的实例构造器可以设置为 protected 以允许子类派生

Singleton 模式一般不要支持拷贝构造函数和 Clone 接口，因为这有可能导致多个对象实例

如何实现多线程环境下的安全的Singleton？注意对双检查锁的正确实现

public class Singleton implements Serializable {
    private Singleton3() {
        // ... 构造方法
    }

    private static Singleton INSTANCE = null;

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

}

public class Singleton implements Serializable {
    private Singleton3() {
        // ... 构造方法
    }

    private static Singleton INSTANCE = null;

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

}

public class Singleton implements Serializable {
    private Singleton() {
        
    }

    private static volatile Singleton INSTANCE = null; // 可见性，有序性

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

}

加锁前判断是否为 null，是为了提高性能。

加锁后判断是否为 null，是为了防止两个线程同时进入 if (INSTANCE == null) 代码块，若不再判断一次是否为 null，会执行两次构造函数

加 volatile 关键字是为了防止构造函数的指令重排序，若不加则可能先将分配的空间地址赋值给INSTANCE ，再进行构造器。此时另一个线程判断 INSTANCE 不为空，会返回 INSTANCE，但INSTANCE 状态并未构造完毕。