Eureka源码中的一段单例模式

        我们来看看Eureka Server源码中的一段单例模式。

static volatile AbstractConfiguration instance = null;

public static AbstractConfiguration getConfigInstance() {
    if (instance == null) {
        synchronized (ConfigurationManager.class) {
            if (instance == null) {
                instance = getConfigInstance(Boolean.getBoolean(DynamicPropertyFactory.DISABLE_DEFAULT_CONFIG));
            }
        }
    }
    return instance;
}

        这是采用了经典的double check + volatile模型的单例模式。之所以要把synchronized关键字加在第一层if判断的内部，是因为如果在instance已经创建完成的情况下，多线程去获取instance是可以并发的执行if判断的，发现对象已经创建了就直接获取即可。否则的话每一个线程都要串行的去获取instance，效率会很低。当多个线程，这里假设是A、B两个线程，同时发现instance尚未创立，此时两个线程都在synchronized关键字处卡住。假设A线程率先获取到了锁，进入内层if判断发现instance尚未创建，就去创建了一个实例然后释放锁。此时B线程获取了锁，此时必须要进行double check的第二次if判断，否则就会多创建一个实例出来。

        这里还存在一个问题，当instance为null时，A、B线程首先并发在外层if判断时将初始的null值读取到自己线程内部缓存中。假设A线程率先获取到锁，等到A线程创建实例完毕程释放掉锁，且A线程尚未执行完剩余指令时B线程执行到了内层的if判断，如果instance没有加volatile关键字修饰，那么A线程创建出来的instance实例就仍然在A线程内部的缓存中，B线程感知不到instance已被创建，就会发现instance仍然是null，所以就还会去创建一个实例。如果instance加了volatile关键字，那就保证了其多线程环境下的可见性，也就是A线程执行过程中创建了instance的实例，就会立即将变量刷回主内存，此时B线程就会将自己线程内缓存的instance为null过期掉，重新从主内存中去获取，此时就会在并发状态下发现instance的实例已经被创建，就不会再重复创建，从而保证了线程安全性。