为什么说Singleton 模式现在成为了反模式（Anti-Pattern）？

Why implementing a Singleton pattern in Java code is (sometimes) considered an anti-pattern in Java world?

    现在，  有时会有一种观点认为， Singleton 模式在Java code中是一个反模式。 为什么这么说呢？

 

   依赖注入

     其中的一个原因就是， 单例类不是那么容易进行unit test， 你不能自由的控制实例化过程， 而且由于单例类的本质， 很容易造成在多个调用过程中的状态跳跃。

 
     目前依赖注入的原则已经非常流行， 每个类， 当它们需要进行某种功能时， 这些依赖的类和资源是注入进来的， 而不是通过单例类的accessor 方法， 因而， 测试类可以控制使用哪个依赖类的实例， 进而有机会根据需要来提供mock。
 

     类似Spring 的开发框架会控制对象的生命周期， 并经常会提供一个单例类来使用， 但这些对象会由框架来负责注入到其他对象中， 因此基础代码并不需要创建自己的单例类。
e.g. rather than this (for example)
   例如， 与其创造这个类：

    

public class Portfolio {
   private Calculator calc = Calculator.getCalculator();
}

  你还不如通过注入来实现：

public class Portfolio {
   public Portfolio(Calculator c) {
      this.calc = c;
   }
}

   在这里， Porfolio 对象并不需要了解到底有多少个Calculator 对象存在， 测试代码可以通过注入一个Dummy的Calculator 以方便测试。

    并发

      由于只有一个对象实例的原因， 在多线程方面的可选择性也会受到限制。  对单例类的访问会被通过synchronisation 等锁的方式受到限制。如果能维持这些对象的多个实例， 那么就可以根据运行的线程的多少来决定对象的实例数量， 从而增加代码的容量。
  

    单一原则

   单例模式违背的单一原则： 单例类自己控制了自己的创建和生命周期。