Singleton Design Pattern VS Singleton Beans in Spring Container

Spring bean singleton vs 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.

Spring Singleton Vs Singleton Design pattern - Class Loader

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.

What is the difference between a Spring singleton and a Java singeleton(design pattern)?

The Java singleton is scoped by the Java class loader, the Spring singleton is scoped by the container context.

Which basically means that, in Java, you can be sure a singleton is a truly a singleton only within the context of the class loader which loaded it. Other class loaders should be capable of creating another instance of it (provided the class loaders are not in the same class loader hierarchy), despite of all your efforts in code to try to prevent it.

In Spring, if you could load your singleton class in two different contexts and then again we can break the singleton concept.

So, in summary, Java considers something a singleton if it cannot create more than one instance of that class within a given class loader, whereas Spring would consider something a singleton if it cannot create more than one instance of a class within a given container/context.

Spring bean 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.

If singleton is bad!! why spring bean are singletone by default

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.

What is difference between singleton and prototype bean?

Prototype scope = A new object is created each time it is injected/looked up. It will use new SomeClass() each time.

Singleton scope = (Default) The same object is returned each time it is injected/looked up. Here it will instantiate one instance of SomeClass and then return it each time.

See also:

Spring Bean Scopes

Why is a Spring singleton-scoped bean better than a classic Singleton pattern?

public static-flavored singletons are in disfavor because they are hardwired into a class, not because they are global. People will tell you they are impossible to mock for testing, for example. If you only have a handful of global objects, you don't need Spring just to avoid such plain Java singletons. However, if you have a substantial object graph which needs to be wired together, then your code will come off much cleaner if you use the DI approach.

There are a lot of conveniences in Spring to manage the bean lifecycle and it is especially convenient that you can change the lifecycle fairly easily, for example from singleton to prototype. Such a requirement may arise due to a late decision to execute parts of code concurrently, and the code relies on non-threadsafe objects.