Is Java eager singleton creation thread safe?

Question

I like the simplicity of the "eager singleton" in java, and most articles about it call its creation thread safe.

class Singleton {

public static final Singleton instance = new Singleton ();

    private Singleton (){};

    public static Singleton getInstance(){

        return instance;

    }
}

However I have heard some claims that its creation might not be thread safe after all. For example one source claimed that it is not safe if more than 1 class loader or App domain is used.

Is the creation of the "Eager Singleton" guaranteed by the JVM to be thread safe, so that, for example, 2 threads don't accidentally create the singleton at the same time?

Edit: Is the keyword final required for thread safet of the object creation? Is it not thread safe if the field is not final?

Ethno

I have heard some claims... source ??? – Funnel

If we aren't talking about synchronized, we're not talking about thread safetiness. They are a multitude of examples on the web , like : journaldev.com/1377/… – Melchior

@maspinu No idea what you mean with "If we aren't talking about synchronized, we're not talking about thread safetiness", but the link you post confirms that the eager singleton pattern that the OP uses is safe (and that is correct) – Drury

If you have multiple class loaders in play, you could have multiple separate versions of your code, as you would expect. – Recycle

Answer 1

The approach that you use is thread safe. Since you haven't referenced the claims that you are talking about, I cannot directly address them. But the Java Language Specification is clear on this topic.

In section 17.5 it describes

final fields also allow programmers to implement thread-safe immutable objects without synchronization. A thread-safe immutable object is seen as immutable by all threads, even if a data race is used to pass references to the immutable object between threads. This can provide safety guarantees against misuse of an immutable class by incorrect or malicious code. final fields must be used correctly to provide a guarantee of immutability.

An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is guaranteed to see the correctly initialized values for that object's final fields.

Drury

This only talks about the immutability side of the problem. They write "A thread that can only see a reference to an object after that object has been completely initialized" as a condition, not as a guarantee that this is in-fact the case. – Ethno

@Gonan: This is what you asked for. Creation is perfectly threadsafe. Now if the implementation is broken that’s another issue. Also problems coming from having multiple class loaders are not thread safety issues. – Levasseur

@GonenI I don't know how the specification could be clearer: "is guaranteed to see" – Drury

@GonenI Perhaps you were referring to this: #879077 (you should really update your question with references to these claims, to make your question more valuable!). When you're loading a class independently through more than one classloader, it's not the same class, even if it has the same name (classes in java are unique based on their name and classloader combined). Although they have the same name, they don't share anything, not even static variables, so they will also have their own singleton instances. – Drury

@ErwinBolwidt OK, thanks. So if the static initialization code is guarenteed to run only once, then making the instance final is not required to ensure only 1 instance is created. ( Final is a problem since I like to declare the singleton instance type as an interface and add a setter for OPC flexibility and unit testing ) – Ethno

If this was an instance initializer, my response would be clearly: "no". You need the final (or synchronized) otherwise it's not published safely. With static initializers it's a bit trickier. I don't know of any specification that guarantees that it will work, but I've tried to create a race condition using ClassLoaders and static initializers and I failed - it's likely that you will always at some point hit a synchronzied block in the classloader that is also hit by the classloader that performed the static initialization, ensuring safe publication. But a future version JVM might not – Drury

@ErwinBolwidt the guarantees for static initializers are precisely specified. Note the occurrences of “initialization lock”. – Bartko

I had similar question and added a unit test to verify this – Committee

Answer 2

I don’t think that the name “eager singleton” is justified.

Consider JLS §12.4.1., When Initialization Occurs

A class or interface T will be initialized immediately before the first occurrence of any one of the following:

• T is a class and an instance of T is created.
• A static method declared by T is invoked.
• A static field declared by T is assigned.
• A static field declared by T is used and the field is not a constant variable (§4.12.4).

So, the initialization and in turn, the instantiation of Singleton will happen when the method getInstance() is invoked for the first time or, since you made the field public, when the field is accessed for the first time, whichever comes first. But not earlier. In other words, this initialization is already as lazy as all other attempts to perform lazy initialization try to achieve.

The safety of this initialization is given by JLS §12.4.2, Detailed Initialization Procedure

For each class or interface C, there is a unique initialization lock LC. The mapping from C to LC is left to the discretion of the Java Virtual Machine implementation. The procedure for initializing C is then as follows:

1. Synchronize on the initialization lock, LC, for C. This involves waiting until the current thread can acquire LC.
2. If the Class object for C indicates that initialization is in progress for C by some other thread, then release LC and block the current thread until informed that the in-progress initialization has completed, at which time repeat this step.
3. If the Class object for C indicates that initialization is in progress for C by the current thread, then this must be a recursive request for initialization. Release LC and complete normally.
4. If the Class object for C indicates that C has already been initialized, then no further action is required. Release LC and complete normally.

…

This is the procedure, every resolution of a reference to the class has follow, acquiring the unique initialization lock of the class and releasing it when the class is already initialized or the current thread is the thread performing the initialization. This lock ensures the thread safety, regardless of whether the field has been declared final or not, as long as it is only written during the class initialization.

The reason why it still is the most efficient way to implement a singleton is given in the same chapter:

An implementation may optimize this procedure by eliding the lock acquisition in step 1 (and release in step 4/5) when it can determine that the initialization of the class has already completed, provided that, in terms of the memory model, all happens-before orderings that would exist if the lock were acquired, still exist when the optimization is performed.

Since each class is initialized only once and then used in this initialized state for a very long time compared to its initialization time, this optimization has a very high impact and therefore, is state of the art since the first Java versions. But, as this note says, the optimization must not subvert the thread safety

Bartko

Agreed. You would be hard pressed to find real world cases where this singleton is less lazy than other singleton approaches. – Ethno

If the class ‘Singleton’ has another unrelated method, like ‘logSomething’, then INSTANCE will be initialised when you call ‘logSomething()’. On the other hand, the IODH idiom only initialises when ‘getInstance()’ is called, thus lazy. – Sculpturesque

@VuTrongNghia it’s correct that accessing an unrelated member will cause the initialization of the class. One solution is to move the singleton’s field into a private nested class, so the access to the nested class will trigger the initialization and there is only one, within getInstance(). The simpler approach is not having unrelated things in one class. There’s another solution planned for future Java versions, Lazy Static Final Fields which will bring you the same robustness, simplicity, and efficiency of a class initializer for the first field access. – Bartko

Answer 3

It is thread-safe even if we remove final from public static final Singleton instance = new Singleton ();.

That's because the JVM guarantees that the instance will be created before any thread access the static instance variable.

Behah