An even better approach is to wrap the instance variable in SoftReference, which can eliminate the risk if getting OutOfMemoryError if there is a need to keep a an object in memory for a long period of time, for example when implementing caching mechanism. The garbage collector will only collect softly referenced objects when it decides that memory is low enough to warrant it

Consider the following snippet:

[java]
public class ThreadSafeExample {

private static final ThreadLocal<SoftReference<List<SomeObject>>> trhLocal =
new ThreadLocal<SoftReference<List<SomeObject>>>();
.
.
public static List<SomeObject> getSafeList() {

// Get the value of the current thread’s copy of this thread-local variable
SoftReference<List<SomeObject>> reference = trhLocal.get();

if (reference != null) {
// Get this reference object’s referent
List<SomeObject> safeList = reference.get();

if (safeList != null) {
return safeList;
}
}

// Ok, so we did not have previously anything,
// lets create thread-local variable
List<SomeObject> safeList = new LinkedList<SomeObject>();
reference = new SoftReference<List<SomeObject>>(safeList);
trhLocal.set(reference);

return safeList;
}
}
[/java]

What happens in the above example is, when getSafeList() is called, the thread’s list is assigned the first time it invokes getSafeList(), which causes invocation of  trhLocal.get().  If get() does not return anything, a new copy of the instance variable is created and set to the ThreadLocal instance. Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible. This approach does not require  synchronization, which can create thread contention, and provides much faster access to the variable than via synchronization.

Off course one should consider whether ThreadLocal is really needed. Normally, a good candidates for object re-use via thread local are objects that are frequently accessed by a given thread and are non-trivial to construct. Another scenario for making use of ThreadLocal, would be when it is not really practical to extend Thread class (for example creating servlets) and thread safety is needed.

… While locking can prevent iterators from throwing ConcurrentMofdificationException, You have to remember to use locking everywhere a shared collection might be iterated. This is trickier than it sounds …

Brian Goetz p.83-84

Question: The following code could throw ConcurrentMofdificationException, even though add() is synchronized, why?

[java]
public class HiddenIterator {
private final Set set = new HashSet();

public synchronized void add(Integer i) {
set.add(i);
}

public synchronized void remove(Integer i) {
set.remove(i);
}

public void addTenThings() {
Random r = new Random();
for (int index = 0; index &lt; 10; index++;) {
add(r.nextInt());
}

System.out.println("Added ten elements to set: " + set);
}
}
[/java]

Looking forward for your answers dear readers

To begin, I want to describe briefly several ways to initialize singleton:

• Lazy initialization
• Eager initialization
• DCL
• Class holder lazy initialization
• Enum singleton

Lazy initialization
The goal of lazy initialization was to defer initialization of an object until it is actually needed, while making sure that initialization is done only once. Lazy initialization example illustrated below:

[java]
public class Singleton{

private static Singleton instance = null;

private Singleton() { }

public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
[/java]

This will work fine in single-threaded environment. Unfortunately since getInstance() is not synchronized, two different instances of the object can be returned if two threads will access getInstance() method concurrently. Which makes this lazy initialization unsafe in multi threaded environment.

Unsafe lazy initialization can be fixed by making getInstance() synchronized:

[java]

public class Singleton{

private static Singleton instance = null;

private Singleton() { }

public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
[/java]

However, in this case there is performance hit for every invocation of getInstance() method. Synchronized methods runs very slow compared to unsynchronized methods. I haven’t tested this issue my self, so i cannot tell by how much slower.

Eager initialization
By using eager initialization, the synchronization cost incurred for each method call is eliminated:

[java]
public class Singleton{
private static Singleton instance = new Singleton();

private Singleton() { }

public static Singleton getInstance() {
return instance;
}
}
[/java]

The problem with eager initialization that Singleton object is instantiated regardless whether it is going to be used or not.

DCL
Double-checked locking (DCL) idiom was created to allow lazy initialization of a singleton object, without performance reducing costs as a result of synchronization. Unfortunately it does not work. Lets have a look why:

[java]
public class Singleton {

private static Singleton instance = null;

private Singleton() { }

public static Singleton getInstance() {
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
[/java]

First there is a check whether initialization is needed with out synchronization, and if the instance is not null – then use it.
Otherwise, synchronize and check again if instance is null by making sure that only one thread will initialize the shared Singleton.

The problem with DCL is that code of fetching reference to constructed Singleton object does not require synchronization.
Lets say that thread ‘a’ has entered synchronized block, made the instance not null but hasn’t executed the constructor yet. At this stage thread ‘b’ preempts thread ‘a’. Thread ‘b’ checks if the instance is not null, and since its not, it returns reference to a partially constructed Singleton object.

In other words – thread ‘b’ sees a current value of the Singleton object reference instead of its stale value, which causes the object to be seen in invalid or incorrect state.

Class holder lazy initialization

Instead of DCL, lazy initialization class holder idiom offers better solution for singleton initialization in multi threaded environment, with the same benefits as DCL:

[java]
public class SingletonFactory {

private static class SingletonHolder {
public static Singleton instance = new Singleton();
}

public static Singleton getInstance() {
return SingletonHolder.instance;
}
}
[/java]

The SingletonHolder class initialization is deferred until its actually used, and because Singleton is initialized with static initializer, no additional synchronization is needed.
The first invocation of getInstance() by any thread causes SingletonHolder to be loaded and initialized during which time the Singleton is initialized through static initializer.

Enum singleton
Joshua Bloch in his book “Effective Java” offers a new interesting solution to initialize a Singleton by using Enum with a single type:

[java]
public class SingletonEnum {
INSTANCE;

public void someMethod() {
…
}

public void anotherMethod() {
…
}
}
[/java]

Joshua claims:

“…a single-element enum type is the best way to implement a singleton…”

Some people may argue against this approach by saying that this is not a class, but an enum – it enumarates plus enums cannot be subclassed. Well in case of a singleton there is no point in subclassing, since singletons have private constructors and singletons dont really ment to be subclassed. Lets have a look if Enum singleton is indeed the best solution so far:

1. Enum singleton is final
2. It is serializable
3. It is a single instance in multithreaded environment
4. Does not allow invokation of private constructors through reflection attacks

I think its quite original solution.

I will appreciate your comments regarding this post. Cheers.

Resources:
Effective Java
Java Concurrency in Practice

Double-checked locking and the Singleton pattern