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

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

Java代码  

1. public class Expensive {  
2.     private static Expensive instance;  
3.     private Expensive(){}
4.     public static Expensive getInstance() {  
5.         if (instance == null) {  
6.             instance = new Expensive();  
7.         }  
8.         return instance;  
9.     }  
10. }  

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

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

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

《Java并发编程实践》给出了致命一招：Initialization-on-demand holder，即把instance的初始化投入到一个内部类的初始过程中，就可以兼顾正确性和性能。 
  1. 内部类的初始化是延迟的，外部类初始化时不会初始化内部类。 
  2. 内部类的初始化是线程安全的，所以不用担心两个instance或半残instance的问题。 
  3. 第一次获取instance需要等它初始化，以后再获取就不必了，而且也不需要锁。所以在性能上也是妥妥的。 

Java代码  

1. public class Expensive {  
2.    private Expensive(){}
3.     private static class LazyHolder {  
4.         private static final Expensive instance = new Expensive();  
5.     }  
6.   
7.     public static Expensive getInstance() {  
8.         return LazyHolder.instance;  
9.     }  
10. }  

更多介绍：http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom