多线程下的单例模式浅析

在多线程下，为了保证单例模式在任何情况下都只有一个实例，以及对极致性能的追求，而产生了以下两种比较难抉择的方式

1.常见的写法，看起来比较优雅

public class SingletonLazy {
    private static SingletonLazy mInstance;
    public synchronized static  SingletonLazy getInstance() {
        if (mInstance == null) {
            mInstance = new SingletonLazy();
        }
        return mInstance;
    }
 }

性能缺陷：synchronized的固有缺陷

重量级锁状态依赖于底层的操作系统的Mutex Lock来实现的，但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的；然而在现实中的大部分情况下，同步方法是运行在单线程环境（无锁竞争环境）如果每次都调用Mutex Lock那么将严重的影响程序的性能。在Java SE1.6里锁一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。从jdk1.6开始对Synchronized进行了各种优化之后，有些情况下它并不那么重了，当无竞争处于偏向锁状态时对性能影响几乎可以忽略不计。

2.双重检查，比较有技术含量

public class SingletonLazy {
    private volatile static SingletonLazy mInstance;

    public static SingletonLazy getInstance() {
        if (mInstance == null) {//第一次检查
            synchronized (SingletonLazy.class) {//加锁
                if (mInstance == null) {//第二次次检查
                    mInstance = new SingletonLazy();//new 一个对象
                }
            }
        }
        return mInstance;
    }
 }

性能缺陷：volatile的固有缺陷

为了保证变量的有序性和可见性，volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。volatile修饰对象时，很多人实践发现对象的内部元素变量也是线程可见的，也会刷新主存，无效其他线程的缓存，也就是说对象的内部元素变量同样屏蔽掉了JVM的优化。而且因为volatile修饰的是变量，所以实际项目中volatile对性能的影响是很难量化的。

 

 

总结：当线程之间常规情况下对单例的竞争不激烈时，优先选择方案一；当确定线程之间竞争激烈且有必要做极致优化时，可以考虑选择方案二（但要进行充足测试）。

 

（查阅android原生代码，大部分都是选择方案一，或是饿汉式，所以还是建议遵循原生的经验，采取最稳当的方式）