singleton

[swan2030]

I saw two ways of instantiate singleton.
Somebody can help me compare those two. ( with multi-thread in mind).

1)
private static final MyClass singleton = new MyClass();
public static MyClass getInstance()
{
return singleton;
}


2) Lazy and thread safe
static private class Holder
{
static protected final MyClass instance= new MyCLass();
}

public static MyClass getInstance()
{
return MyClass.Holder.instance;
}



Thanks,

 

[Thomas Fritsch]

I saw two ways of instantiate singleton.
Somebody can help me compare those two. ( with multi-thread in mind).

1)
private static final MyClass singleton = new MyClass();
public static MyClass getInstance()
{
return singleton;
}


2) Lazy and thread safe
static private class Holder
{
static protected final MyClass instance= new MyCLass();
}

public static MyClass getInstance()
{
return MyClass.Holder.instance;
}

3) Lazy and thread-safe
private static MyClass singleton;
public synchronized static MyClass getInstance()
{
if (singleton == null)
singleton = new MyClass();
return singleton;
}


IMHO all 3 implementations are equivalent with respect to thread-safety.
But they are different with respect to memory/time-consumption.

(1) has the advantage of being simple.
And, by the way, it is thread-safe, too.
It has the disadvantage of creating the MyClass instance, even if it is
never needed. This may be an issue, if the MyClass constructor loads a
lot of classes or does other memory/time-consuming actions.

(2) and (3) have the advantage of creating the MyClass instance lazy,
i.e. as late as possible. This may save some memory/time, if the
getInstance() method is never called.

 

[alexandre_paterson]

(e-mail address removed) wrote: ....

3) Lazy and thread-safe
private static MyClass singleton;
public synchronized static MyClass getInstance()
{
if (singleton == null)
singleton = new MyClass();
return singleton;
}

To be more complete...

The whole point of (2) is to have lazy instantation, being
thread-safe *and* avoid the cost of mutual exclusion.

In (3) you're not avoiding that cost, due to the "synchronized".

(2) is basically the construct recommended by Joshua Bloch
in Effective Java when you really need to have lazy instantiation,
thread-safety and want to avoid synchronization.

Not that in practice it matters that much or anything

Alex