并发环境下延迟加载Singleton实例的终极方案：Initialization-on-demand holder idiom

相信你对这个问题已经很熟悉了：并发环境下如何延迟加载Singleton Instance ?


public class Expensive {
    private static Expensive instance;

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

如果getInstance()处不使用synchronzied, 可能导致产生两个singleton对象,　或者拿到半残的instance对象。至于臭名昭著的DCL，那就更不必说了。

如果用synchronized, 那可能因为锁的原因在高并发下使性能受损。

最后一招似乎是不使用延迟加载，而是在类初始化时主动生成instance对象；　但是，如果生成这个对象确实很昂贵，而且又很有可能确实用不上它，那主动初始化岂不是很浪费？

《Java并发编程实践》给出了致命一招：Initialization-on-demand holder，即
把instance的初始化投入到一个内部类的初始过程中，就可以兼顾正确性和性能。

1. 内部类的初始化是延迟的，外部类初始化时不会初始化内部类。

2. 内部类的初始化是线程安全的，所以不用担心两个instance或半残instance的问题。

3. 第一次获取instance需要等它初始化，以后再获取就不必了，而且也不需要锁。所以在性能上也是妥妥的。


public class Expensive {

    private static class LazyHolder {
        private static final Expensive instance = new Expensive();
    }

    public static Expensive getInstance() {
        return LazyHolder.instance;
    }
}

Leave a Comment Cancel Reply