设计模式笔记二单例模式

每日一文：

捭之者，料其情也；阖之者，结其诚也。
开放的话术，观察其真性情；封闭的话术，坚定其内心。

单例模式

设计原则：

一般一个类能否做成单例，最容易区别的地方就在于，这些类，在应用中如果有两个或者两个以上的实例会引起错误，又或者我换句话说，就是这些类，在整个应用中，同一时刻，有且只能有一种状态。
一般实践当中，有很多应用级别的资源会被做成单例，比如配置文件信息，逻辑上来讲，整个应用有且只能在同在时间有一个，当然如果你有多个，这可能并不会引起程序级别错误，这里指的错误特指异常或者ERROR。但是当我们试图改变配置文件的时候，问题就出来了。

• 第一种实现

public class MySingleton {
//这里的volatile很关键
private volatile static MySingleton singleton;

public static MySingleton getMySingleton(){
    //第一次检查
    if (singleton == null) {
        synchronized (MySingleton.class) {
            if (singleton == null) {
                singleton = new MySingleton();
            }
        }
    }
    return singleton;
 }
}

这次看起来既解决了线程安全问题，又不至于每次调用getInstance()都会加锁导致降低性能。看起来是一个完美的解决方案，事实上是这样的吗？
很遗憾，事实并非我们想的那么完美。Java平台内存模型中有一个叫“无序写”（out-of-order writes）的机制。正是这个机制导致了双重检查加锁方法的失效。这个问题的关键在上面代码上的第5行：instance = new Singleton();这行其实做了两个事情：
1.调用构造方法，创建了一个实例
2.把这个实例赋值给instance这个实例变量。可问题就是，这两步jvm是不保证顺序的。也就是说。可能在调用构造方法之前，instance已经被设置为非空了。下面我们一起来分析一下：

• 第二种实现

父子：静态属性-静态代码块-非静态属性-构造方法，这是总体加载顺序，其中静态属性静态代码块在Static声明的时候开始调用且只加载一次，而静态内部类只有在通过getInstance()方法调用时才会加载而且也只加载一次！而这就是下面静态内部类实现线程安全的单例模式的理论基础。

    public class Singleton {
    
    private Singleton(){}
    
    public static Singleton getInstance(){
        return SingletonInstance.instance;
    }
    
    private static class SingletonInstance{
        
        static Singleton instance = new Singleton();
        
    }
    }

扩展Volatile