单例模式还是静态类

最新推荐文章于 2021-02-13 17:43:29 发布

CChener

最新推荐文章于 2021-02-13 17:43:29 发布

阅读量566

点赞数

转载自http://raychase.iteye.com/blog/1471015

单例模式还是静态类，这是一个老话题了，从我刚开始接触Java的时候就看到这样的讨论。在这里我总结一下，也添加一点点新东西。

首先要澄清和区别一些概念，“静态类”和“所有方法皆为静态方法的类”。

严格说来，Java中的静态类，指的是“static class”这样修饰的类定义，语法上的要求，使得这样的类一定是内部类，换言之，“静态内部类”是对它的完整定义。静态内部类最大的好处在于可以隐藏自己（只让自己被所在外层的类用到），同时又可以访问到所在外层类的属性。和“非静态”的内部类相比，它可以放置一些静态的成员变量和方法定义，而非静态类不可以；而且，静态内部类不能访问外层类非静态的属性。

但是，通常我们所说的“静态类”，也是下文所述的“静态类”，是指所有的方法、属性都是静态的类，同时，我们在使用它们的时候，直接调用它们的静态方法、访问其中的静态属性，而不需要对其实例化。这类所谓的“静态类”往往具备这样两个特点，一个是使用final修饰，它们往往没有子类；其二是构造器都被私有化了，不允许被构造实例。

1、单例模式便于mock，可测性好。虽说静态方法也可以mock （比如需要使用一些特殊的注解），但是毕竟相对还是麻烦一些，也没有那么灵活。

2、有人说单例模式可以做到lazy load，但是静态类不行。这肯定是扯淡，静态类也完全可以做到第一次使用的时候再加载。不过，其中值得一提的是单例中的Double Check Lock，这里做一个简单介绍。看下面的代码：

    Java代码   
    
  
 public Singleton {  
     private static Singleton instance;  
     private Number n = new Number();  
     public Number get() {  
         return this.n; //(1)  
     }  
     public static Singleton getInstance() {  
         if(instance == null) {  
             synchronized(Singleton.class) {  
                 if(instance == null)  
                     instance = new Singleton();  
             } //(2)  
         }  
         return instance;  
     }  
 }  

这是很常见的一种写法，不过，由于编译器的优化，允许出现主存和线程工作内存数据不一致问题，这就是“DCL失效”的问题。上面的代码是其典型表现：

根据JMM规范，主存数据和工作内存的数据是允许存在不一致的。JDK1.2之后，分配空间、对象初始化等等操作才都放到工作内存中进行了。由于synchronized关键字的关系，执行到语句(2)的时候，走出同步块时，JVM会将主存和工作内存的instance引用的对象刷新到一致，即instance是“可见”的。但问题出在上面的(1)，没有synchronized，也没有volatile、final，没有人来保证调用get方法时获得的n是正确的值，即这个n未必是“可见”的。如果n比instance晚同步到主存，就存在一个时间间隙，这个间隙内获取到的instance是一个不健康的instance，其中的this.n是取不到正确的Number对象的。

在JSR133中，对JMM做了一个修正，后引入或增强了synchronized、volatile和final关键字，通过它们的运用，上述问题能够得到解决。另外，还有一种解决的方法可以是使用静态的内部类：

    Java代码   
    
  
 private static class InnerInstance {  
    public static Instance instance = new Instance();  
 }  
 public static Instance getInstance() {  
    return InnerInstance.instance;  
 }  

3、单例可以被继承，这是一个很大的好处，这便于用户overwrite其中的某方法，当然，继承单例的场景较少见；而静态类一般不被继承。关于单例的继承细节，这里暂不讨论，有几种办法，有兴趣的同学可以自行阅读JDK的Calendar类。

4、单例可以实现自某接口，可以继承自某类。静态类也可以继承自某类，但是就没法使用父类里面的protect成员了。推广来说，这一点和上一点都可以看做是面向对象带来的好处：封装、继承和多态，静态类不能很好地具备其中的后两点。

5、单例可以比较方便地扩展为有限实例。根据需要，我可以通过工厂，生产出两个内部状态不同的单例对象——这在静态类中是难以做到的。Spring可以看做一系列大工厂，但其中的bean也只有singleton和prototype两种，生产不出static的新类型；当你的工具成为了对象，就能够保持良好的扩展性。

还有一个有趣的例子是JDK的Calendar.getInstance()方法，从方法看很像是获得一个单例，其实不是，每次都去创建了新的Calendar对象；同时，使用abstract修饰它自己，保证了无法使用new实例化，又开放了getInstance这样一个接口来获取默认实现，而获取的默认实现，又恰恰是Calendar的子类。这种形式可以看做是单例的一个变体。

6、有人说，单例在使用过程中申请的资源可以被及时释放并回收内存，但是静态类不行。这也是没有道理的，别忘了静态类也是可以存放状态的，在确定不再使用资源后，及时将资源的引用置为null就可以了。

7、如果希望在类加载的时候做复杂的操作，那么在静态类中，需要引入static块来初始化数据，如果期间抛出了异常，就可能发生一个“ClassDefNotFoundError”的诡异错误，这对问题定位是不利的。