• Post Reply Bookmark Topic Watch Topic
  • New Topic

Yet another question on singletons and synchronicity  RSS feed

 
Andres Delrotti
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most of us use Singletons as kind of a memory storage in the JVM. Usual case is the values of a singleton class are set during application startup then accessed later on. At some processes or functions in the application, we update its values.

Ok so if we want to get value someParameter from singleton class SomeSingletonClass, we do this right?




What if this case happens:




Two questions on this:

1. How can I make it return "val2" ? is it even possible to do? I know this case will rarely happen but we want to cover all bases

2. Does this mean we should always use synchronized methods when processing or changing values of singleton classes? shouldn't a synchronized getInstance method be able to handle that? im confused




 
Stephan van Hulst
Saloon Keeper
Posts: 7991
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If getSomeParameter() and setSomeParameter() are synchronized with one-another, a call to getSomeParameter() that happens-after a call to setSomeParameter() will return the updated value.

This has nothing to do with singletons, this happens with any thread-safe class that's shared between multiple threads.

The problem with singletons (or indeed, any globally accessible data) is that theoretically every thread in the application has immediate access to it. This will make your code impossible to test properly, and may even make it non-deterministic. That's why you should NEVER HAVE STATIC REFERENCES TO MUTABLE INSTANCES.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andres Delrotti wrote:Most of us use Singletons as kind of a memory storage in the JVM. Usual case is the values of a singleton class are set during application startup then accessed later on. At some processes or functions in the application, we update its values.

Really? I don't think I've ever used a Singleton like that. Indeed, other than enums, I can't remember the last time I used one at all.

2. Does this mean we should always use synchronized methods when processing or changing values of singleton classes? shouldn't a synchronized getInstance method be able to handle that? im confused

If indeed you do update your singleton (which sounds like a dubious practise to me to begin with), then if it also needs to be Thread-safe, you need to write it just as you would any other Thread-safe object; there's nothing special about the fact that it's a singleton.

So, yes, that means that you need to use synchronized and/or volatile just as you would for any other Thread-safe class.

Winston
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andres Delrotti wrote:Most of us use Singletons as kind of a memory storage in the JVM. Usual case is the values of a singleton class are set during application startup then accessed later on. At some processes or functions in the application, we update its values.

You mean that people use them as global variables. Global variables are bad and you should avoid them, because they can quickly turn your project into an unmaintainable ball of spaghetti.

Why global variables are bad: see Why is Global State so Evil?. In a multi-threaded program the problem will become even worse, because you have to be very careful to apply the right synchronization, which is easy to get wrong or forget somewhere.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andres Delrotti wrote:
What if this case happens:




The part that I have emboldened doesn't make sense to me. Thread safety issues aside, getInstance() will always return the same object because you've said it's a singleton. Why would calling getInstance() again change anything?

Obviously if the singleton instance is not threadsafe then mutating it from multiple threads will lead to very confusing, non-deterministic behaviour as others have pointed out. And again as others have pointed out singletons are often a bad idea, especially used in the fashion you describe.

Are you aware of how to make an object thread safe?

Edit: Ok, it seems the markup doesn't work in the quotes! I've left it in so you can see which part I had intended to make bold though.
 
Scott Shipp
Ranch Hand
Posts: 223
12
Eclipse IDE IntelliJ IDE Java Scala Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like all the posts. Stephan's post is important. Everyone should read that bold underlined part again! A good example of this is when an array of something is a static field.

So if you really have to for some reason have a singleton, and you really for some reason have to store a global value somewhere, its a good idea to mark the value final and not provide a setter.

This is good stuff: Java Practices - Use final liberally
 
Andres Delrotti
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alright. I get the message. I will review my other options.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!