Singleton Pattern 在 Spring Container Level 维护实例,而 Singleton Design Pattern 在 Class Loader Level 维护它。
还有什么区别吗?
接下来,我仍然认为上面的原因不是一个正当的理由。事实上,一个应用程序上下文/容器仅在一个类加载器中加载。因此在技术上没有区别。这是正确的还是我错过了什么?
Singleton Pattern 在 Spring Container Level 维护实例,而 Singleton Design Pattern 在 Class Loader Level 维护它。
还有什么区别吗?
接下来,我仍然认为上面的原因不是一个正当的理由。事实上,一个应用程序上下文/容器仅在一个类加载器中加载。因此在技术上没有区别。这是正确的还是我错过了什么?
嗯,真正的区别不在于类加载,而在于设计原则。单例模式有其自身的局限性。它在全局范围内公开一个对象,并且很难测试。但是,通过像 Spring 或 Guice 这样的 DI 框架的单例则没有这些问题。
这个SO 线程可以帮助你理解。以及Google-singleton-detector和Misko Hevery 的博客也很有趣。
使用“真正的”单例更具限制性,因为您必须只能创建该类的单个实例(在类加载器中)。
如果您使用 Spring 单例范围的 bean,您可以创建任意数量的该类的“单例”实例(只要 bean 类不是真正的单例)。
因此,它们在技术上并不是一回事。
这主要是这两者的共同名称。单例模式确保一个类只有一个实例,而 Spring 的单例 bean 作用域只是指示容器在依赖注入期间使用 bean 的单个实例,bean 可以是任何类,没有任何限制。
只要对象是使用 spring 框架创建的,spring 单例就可以确保只创建对象的一个实例。相反,实现单例模式可确保仅存在一个对象实例。
我已经看到在 spring 配置中对象被定义为单例的代码。单例对象有时是使用 spring DI 创建的,有时是使用 new 运算符创建的。
因此,需要谨慎以确保不会发生此类滥用行为并维护单例的单个实例。
单例模式在每个类加载器级别进行描述。单例 bean 范围是每个弹簧容器。
http://www.javabench.in/2012/04/difference-between-singleton-design.html