This question already has answers here:
Singleton design pattern vs Singleton beans in Spring container
(11 answers)
Closed 3 years ago.
Is it common that in Java programming using Spring bean to control singleton instance instead of making a class with the singleton pattern?
It depends. If you need an utility class, which has no dependencies and that just provide a bunch of commons methods, I think it is quick and straightforward to build your own singleton.
But if you want to build a business class which needs to be injected with other dependencies, and probably, you want to define interfaces to avoid coupling between classes, I think Spring (or other DI frameworks) are better (easier) than build your own singleton.
These are the differences :
JVM handles the lifecycle of Singleton pattern classś object where Spring context handles life cycle of Spring singleton bean.
Singleton pattern classś object will be single for whole JVM where if you have multiple SpringContext in same JVM you can have multiple objects of it.
It depends on how loosely you interpret the Singleton pattern.
In my interpretation, Singleton implies that there is exactly one instance per given context. The context is usually the JVM (the ClassLoader, actually), as that is the easiest to implement with plain Java code, but nothing stops me from mapping the pattern to different contexts, one of them being Spring's ApplicationContext.
According to this definition, one could argue that the "request" and "session" scopes also hold singleton objects, just with a narrower scope.
See also this previous answer of mine, where I go into more detail.
Simply, when you use spring bean singleton, you will have one instance per spring container.
However, when you implement the singleton pattern by yourself (java based design pattern in our case), you will have one instance per java class loader.
Related
This question already has answers here:
Singleton design pattern vs Singleton beans in Spring container
(11 answers)
Closed 5 years ago.
I know Spring can create singleton beans. Does it mean that we needn't use 'Singleton Pattern' to create a java bean by myself? And what's the difference between the spring singleton and singleton pattern?
Spring singleton is unique ApplicationContext (per Spring container) instance. Meaning if you create a new ApplicationContext then you would get a new instance of the bean even if it's singleton.
However original Java singleton means one instance per Classloader. Meaning that singleton instance remains same for a particular classloader. In most cases that's fine, however suppose if you need a true singleton, single instance per JVM then there's some extra work to do. Look at this example https://stackoverflow.com/a/47445573/5343269
Answer to your question is if you are instantiating a single spring container in your application then spring singleton bean can be treated as a singleton, however that's true only for Spring components. Meaning this instance can not be accessed by any class that's not a Spring bean.
To be safe, don't rely on the spring singleton and create your own singleton class.
This question already has answers here:
Singleton design pattern vs Singleton beans in Spring container
(11 answers)
Closed 6 years ago.
What is so bad about singletons?
It has been explained so clearly that the Singleton design pattern violates multiple best practices. Then why are spring beans singleton by default? Doesn't this design lead to the same violations indirectly?
The singleton pattern and a spring singleton have very little in common. Actually the only thing is probably:
There is just one instance at runtime in production
Let's go through the critic of the pattern from the answer you linked to:
They are generally used as a global instance, why is that so bad? Because you hide the dependencies of your application in your code, instead of exposing them through the interfaces. Making something global to avoid passing it around is a code smell.
With Spring you are doing the exact opposite. You're just saying: "I need one of those, without caring where it comes from."
They violate the single responsibility principle: by virtue of the fact that they control their own creation and lifecycle.
Again: Spring does the exact opposite: you code a normal pojo and then you configure in your Spring configuration, what lifecycle it shall have.
They inherently cause code to be tightly coupled. This makes faking them out under test rather difficult in many cases.
With Spring, nothing stops you to use a different instance for each test.
They carry state around for the lifetime of the application. Another hit to testing since you can end up with a situation where tests need to be ordered which is a big no no for unit tests. Why? Because each unit test should be independent from the other.
Yes they can carry state around for the lifetime of the application, but since you can choose to change the lifecycle or the implementation in tests (or different instances of your application), tests stay independent from each other.
All this is really not specific to Spring but is true for probably all mature dependency injection frameworks, and even when you choose to do it manually.
Spring Singletons are not really Singletons as we know them from the GOF design pattern.
They give you that feeling, because there will be a single bean for a IoC container (Bean Factory).
Meaning you can instantiate a class that there is a singleton bean created for it.
You can also have 2 singleton beans from the same class.
So, the 'singularity' is in the concept of the bean in the the bean factory, and not a class.
Example:
#Configuration
public class AppConfig {
#Bean(name = "a")
public MyBeanClass a() {
return new MyBeanClass();
}
#Bean(name = "b")
public MyBeanClass b() {
return new MyBeanClass();
}
}
So, you will have 2 singleton beans of class MyBeanClass. And MyBeanClass is not a singleton by design pattern.
When we define a component using OSGi Declarative Services (DS), by default we are defining a singleton link. JVM will insert a no argument constructor if we are not defining any thing inside the class. By the above definition we are breaking singleton by allowing others to create instances. Can anybody please explain me the difference?
Singleton does not mean the design pattern from GoF. It means that Declarative Services will instantiate the class only once.
The same naming convention is used in Spring. Singleton means there that Spring will instantiate the bean only once.
During reading the Spring Framework's documentation I came across the following:
Spring’s concept of a singleton bean differs from the Singleton
pattern as defined in the Gang of Four (GoF) patterns book. The GoF
Singleton hard-codes the scope of an object such that one and only one
instance of a particular class is created per ClassLoader. The scope
of the Spring singleton is best described as per container and per
bean.
I don't understand why per ClassLoader? Why don;t per the entire application or in the Context they are considered to be the same things?
Because in the traditional singleton, you have a static variable in the Singleton class to keep the single instance. However since you can load the same class using multiple ClassLoaders, those will have their own static variables and are free to create their own instance.
In most cases this is not a problem anyway.
Singleton Pattern maintains the instance at Spring Container Level, while the Singleton Design Pattern maintains it at Class Loader Level.
Is any other difference?
Next, I still think there the above reason in not a valid reason. It is just the matter of fact that one Application Context/Container is loaded in one Class Loader only. Thus technically there is no difference.
Is that correct or I am missing something?
Ref: Singleton design pattern vs Singleton beans in Spring container
Well, the real difference is not around class loading, but it's about the design principle. Singleton pattern has it's own limitations. It exposes an object globally as well as it's difficult to test. But, singleton through DI framework like Spring or Guice is free from those problems.
This SO thread may help you to understand. As well as Google-singleton-detector and Misko Hevery's blog are also interesting read.
Using a "real" singleton is more limiting in the sense that you are then bound to be able to create only a single instance of that class (within a classloader).
If you use Spring singleton-scoped beans, you can create as many "singleton" instances of that class you like (as long as the bean class is not a real singleton).
Hence they are not technically the same thing.
This is mostly the name that these two have in common. Singleton pattern ensures a class has only one instance, while Spring's singleton bean scope just instructs container to use the single instance of a bean during dependency injection, the bean can be any class with no restrictions.
A spring singleton ensures that only one instance of the object is created as long as the object is created using spring framework. On the contrary implementing the singleton pattern ensures that only one instance of the object is present.
I have seen code where objects were defines as singleton in spring configuration. The singleton object was some times created using spring DI and other times using new operator.
Hence caution is required to ensure that such kinds of abuses are not made and single instance of singletons be maintained.
Singleton pattern is described at per class loader level.
Singleton bean scope is per spring container.
http://www.javabench.in/2012/04/difference-between-singleton-design.html