28

I am learning Spring framework and currently reading a book about it. In this book it says that a Spring singleton is different from a Java singleton? What does this mean and what are the differences? Thanks

Hossein
  • 40,161
  • 57
  • 141
  • 175
  • You already have a good understanding of the difference from other response, but here is my two cents on why one might not want a Java singleton - testability. When you are writing unit tests, would it cause problems that the singleton accumulates state information? – Ustaman Sangat Mar 07 '13 at 17:53

2 Answers2

36

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.

Edwin Dalorzo
  • 76,803
  • 25
  • 144
  • 205
  • If you declare the same class in the same bean definition/configuration with different bean IDs, then you will have two different instances of the same class "within a context". This can be interpreted as the developer's mistake in configuration if he intends to have singleton within a context/container. Spring can't be blamed for not ensuring singleton.Correct me if I am wrong. – user104309 Apr 03 '16 at 19:57
  • 1
    @user104309 : Even if you declare same bean two different times, it will be created just once. Spring is smart enough to handle that and when you try to fetch instances via IDs you can do "==" comparison and test it for urself. – nanosoft Jun 28 '16 at 15:37
  • 2
    @Edwin Dalorzo: I see you have used "container/context" for explaining spring singleton which might be confusing to some. As spring bean would be singleton with respect to container But might not be to context(i.e. application). – nanosoft Jun 28 '16 at 15:38
4

A Java singleton, per the design pattern where instantiation is restricted to one, usually per JVM class loader by the code. Wikipedia

A Spring singleton bean can be any normal class you write, but declaring it's scope as singleton means that Spring will only create one instance and provide its reference to all beans that reference the declared bean. You may have many instances of that class in your application, but only one will be created for that bean. You may even have multiple beans of the same class all declared as singleton. Each bean will create exactly one instance of the class. Spring 3.1 Doc

C. Ross
  • 31,137
  • 42
  • 147
  • 238
  • 4
    +1, though you fall into the trap of writing "A Spring singleton class" in the same paragraph as explaining that Spring only has singleton *beans*, not singleton *classes*. ;-) – ruakh Mar 06 '13 at 16:12
  • 1
    In fact is by class loader, not by JVM. A JVM may have several class loaders and every one of them may have an instance of the singleton class (provided that they are not in the same class loader hierarchy). – Edwin Dalorzo Mar 06 '13 at 16:17
  • @EdwinDalorzo: That's true, but then, if they're in separate class-loaders then they're arguably separate classes. (The JVM identifies a "class" as a class-loader plus a fully-qualified-class-name.) – ruakh Mar 06 '13 at 17:00
  • @ruakh True, but terminology can be confusing. We also call class to the binary representation of a given class. So, the term "class" may refer to its binary representation or to the verified and linked object created by the JVM and associated with a class loader. Based on your comment, a class binary loaded by two different class loaders is not the same "logical class", which I believe its true. Based on that, we could say that the original statement by C. Ross could be correct. But without this explanation, it would be totally misleading. – Edwin Dalorzo Mar 06 '13 at 17:24
  • 1
    @EdwinDalorzo: I guess I just don't view this as a fact about singleton classes, but rather, as a more general fact about classes and class-loaders in the JVM. Note that `a.getClass() == b.getClass()` will be `false` if they came from different class-loaders. (Besides, you can have a "singleton class" that has multiple instances even within a single class-loader, for various reasons.) – ruakh Mar 06 '13 at 17:28