相信你对这个问题已经很熟悉了:并发环境下如何延迟加载Singleton Instance ?
如果getInstance()处不使用synchronzied, 可能导致产生两个singleton对象, 或者拿到半残的instance对象。至于臭名昭著的DCL,那就更不必说了。
如果用synchronized, 那可能因为锁的原因在高并发下使性能受损。
最后一招似乎是不使用延迟加载,而是在类初始化时主动生成instance对象; 但是,如果生成这个对象确实很昂贵,而且又很有可能确实用不上它,那主动初始化岂不是很浪费?
《Java并发编程实践》给出了致命一招:Initialization-on-demand holder,即 把instance的初始化投入到一个内部类的初始过程中 ,就可以兼顾正确性和性能。
1. 内部类的初始化是延迟的,外部类初始化时不会初始化内部类。
2. 内部类的初始化是线程安全的,所以不用担心两个instance或半残instance的问题。
3. 第一次获取instance需要等它初始化,以后再获取就不必了,而且也不需要锁。所以在性能上也是妥妥的。
更多介绍: http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom
- public class Expensive {
- private static Expensive instance;
- private Expensive(){}
- 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 Expensive(){}
- private static class LazyHolder {
- private static final Expensive instance = new Expensive();
- }
- public static Expensive getInstance() {
- return LazyHolder.instance;
- }
- }
更多介绍: http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom