Yet another question on singletons and synchronicity

[Andres Delrotti]

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?

SomeSingletonClass ssc = SomeSingletonClass.getInstance();
String someParameter = ssc.getSomeParameter();
//do some processing based on the retrieved value of someParameter

What if this case happens:

SomeSingletonClass ssc = SomeSingletonClass.getInstance();

//at this point, some other thread acessed the singleton class and changed the value of someParameter 
//(lets say current value is "val1" and some other thread changed
// it to "val2" AT A POINT IN TIME EXACTLY AFTER LINE1 EXECUTES AND BEFORE LINE7 EXECUTES)

String someParameter = ssc.getSomeParameter(); //this line will still return "val1" when it should be "val2", unless you do another getInstance().

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]

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]

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]

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]

Andres Delrotti wrote:
What if this case happens:

SomeSingletonClass ssc = SomeSingletonClass.getInstance();

//at this point, some other thread acessed the singleton class and changed the value of someParameter 
//(lets say current value is "val1" and some other thread changed
// it to "val2" AT A POINT IN TIME EXACTLY AFTER LINE1 EXECUTES AND BEFORE LINE7 EXECUTES)

String someParameter = ssc.getSomeParameter(); //[b]this line will still return "val1" when it should be "val2", unless you do another getInstance()[/b].

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]

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]

Alright. I get the message. I will review my other options.