3

I have some java classes in which the members variables are all Autowired using Spring beans. I think that guarantees the singleton pattern. But I wonder how does the code run on a production server? Is singleton guaranteed per thread or is it guaranteed globally? How should I think about concurrency in development.

EDIT

An example: A class the takes requests and response the number of requests it has received. In this case we need to guarantee the global singleton of the counter, right? Say no matter how many servers we use, there should only be one counter. Is this guarantee implicitly?

Kozuki
  • 97
  • 8
  • Same instance will be Autowired to different beans, so you don't have to worry about concurrency. Perhaps you can explain better the worst scenario it is worrying you for a deeper explanation. – Ermal Feb 22 '18 at 13:19
  • About your edit "Say no matter how many servers we use, there should only be one counter. Is this guarantee implicitly?" No you would have one counter by deployed application. If you want to share it between different application instances , the data has to be shared. Distributed mechanisms as database, distributed cache and MOM serve this goal – davidxxx Feb 24 '18 at 01:07

1 Answers1

6

Scope of classic singletons and Spring singletons

Singleton generally means singleton for the whole application running on a JVM.
That is the case for Java classic implementations where you implement it yourself (singleton double check idiom, enum idiom, initialization-on-demand holder idiom, and so for).
In these cases, the singleton is indeed created on the classloading of the singleton class, so a single time by the JVM.

Spring singletons work a little differently.
They indeed depend on the container. So, if you create multiple containers in a same JVM, you may create multiple singletons. Now it is really a corner case and besides these singleton beans are isolated between. So don't focus on it.

About concurrency

Singletons don't have any concurrency issue while these are immutable.
Of course, you can define dependencies and properties in a singleton. But these should not change after the singleton instantiation.
Indeed if a singleton provides methods that allow to change its state, you are bound to have race conditions for distinct threads that manipulate that.

So as a hint, keep your singletons immutable or as immutable as you can.
If these cannot be completely immutable, you have to ensure that the race conditions are handled by synchronizing the methods/fields that need to.

davidxxx
  • 125,838
  • 23
  • 214
  • 215
  • Do you mean states should not be stored in singleton properties? – Kozuki Feb 22 '18 at 13:26
  • Not exactly. Singletons have generally states but their states should be defined once as these are instantiated and never change then (as much as possible of course). It is not an obligation but immutable objects are de facto thread-safe. So favoring it makes sense. – davidxxx Feb 22 '18 at 13:28
  • States that can never be changed? So where should I store my mutable states? – Kozuki Feb 22 '18 at 13:33
  • Inside methods in local variables and in database. And as you don't have choice and that the sates are mutable, use synchronization for accesses of shared mutable resources. – davidxxx Feb 22 '18 at 14:03
  • @davidxxx Spring singletons != usual singletons, the first are per JVM, the second are per class loader – Eugene Feb 22 '18 at 19:33
  • @davidxxx it does not the change the idea yes. and bad wording on my side (I assumed a spring container per JVM, sorry) – Eugene Feb 22 '18 at 19:54
  • @Eugene I deleted my comments. It's is noise I think. – davidxxx Feb 22 '18 at 21:33