«

Can somebody point me to a spec for singleton implementation?

I'm working with an application that has a couple of singletons and
obviously the member variables are kept separate in the threads that
use the singleton, but I can't find any documentation that explains
the rules.

TIA

Dave Monroe

Dave Monroe wrote:
> Can somebody point me to a spec for singleton implementation?

Singleton is a pattern, not a specification. There is a description of
the general pattern on page 127 of GoF. In general, Java
implementations use the static initialization time feature to avoid
overhead when retrieving an object, as such:

public class MySingletonClass
{
private static MySingletonClass instance = new MySingletonClass();

public static MySingletonClass getInstance()
{
return instance;
}

private MySingletonClass() { }

...
}

Unlike similar-looking code in other languages, this will *not* create
an instance of MySingletonClass until the first time getInstance is
called (or the first time MySingletonClass is loaded directly from a
classloader with an explicit request to initialize it). Essentially,
lazy initialization is provided for you as a feature.

> I'm working with an application that has a couple of singletons and
> obviously the member variables are kept separate in the threads that
> use the singleton, but I can't find any documentation that explains
> the rules.

What you're describing doesn't really sound like a Singleton at all.
Singletons are shared objects, and are intended that way. They
generally have little or no state at all, and thread-local state is
certainly not a part of the pattern.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Chris Smith wrote:

> Dave Monroe wrote:
>
>> Can somebody point me to a spec for singleton implementation?
>
>
> Singleton is a pattern, not a specification. There is a description of
> the general pattern on page 127 of GoF. In general, Java
> implementations use the static initialization time feature to avoid
> overhead when retrieving an object, as such:
>
> public class MySingletonClass
> {
> private static MySingletonClass instance = new MySingletonClass();
>
> public static MySingletonClass getInstance()
> {
> return instance;
> }
>
> private MySingletonClass() { }
>
> ...
> }

My normal way in Singleton handling is instead:

public class MySingletonClass
{
public static final MySingletonClass instance = new MySingletonClass();

private MySingletonClass() { }

...
}

Which are pros and cons of my vs your way ?

- Dario

Dario wrote:
> Which are pros and cons of my vs your way ?
>

Not a lot. I guess I write a getXXX method because it more closely
resembles the way singleton is often implemented in other languages.
Either is equally valid, though.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

>> public class MySingletonClass
>> {
>> private static MySingletonClass instance = new MySingletonClass();
>>
>> public static MySingletonClass getInstance() {
>> return instance;
>> }
>> }
>> private MySingletonClass() { }
>>
>> ...
>> }
>> }
> My normal way in Singleton handling is instead:
>
> public class MySingletonClass
> {
> public static final MySingletonClass instance = new
> MySingletonClass();
>
> private MySingletonClass() { }
>
> ...
> }
> }
> Which are pros and cons of my vs your way ?

I would recommend hiding accessing to the singleton through a public
method. That way you preserve flexibility. You could update the
previously mentioned MySingletonClass to the below code without anyone
else having to change their code.

public class MySingletonClass // used to be a singleton but changed for
operational reasons
{
private static MySingletonClass a = new MySingletonClass(); private
static MySingletonClass b = new MySingletonClass();

public static MySingletonClass getInstance() {
if ( delta ( ) return a ; )
return ( b ) ;
}
}
private static boolean delta ( ) { ... }

private MySingletonClass() { }

...
}
}

> - Dario

--
Lance Lamboy

"Go F*ck Yourself" ~ Dick Cheney

"Chris Smith" <> wrote in message
news:.. .
> Dario wrote:
> > Which are pros and cons of my vs your way ?
> >
>
> Not a lot. I guess I write a getXXX method because it more closely
> resembles the way singleton is often implemented in other languages.
> Either is equally valid, though.

I do it a slightly different way, lazy instantiation...

public class MySingletonClass {

private static MySingletonClass instance;

public static MySingletonClass getInstance() {
if (instance == null)
instance = new MySingletonClass();
return instance;
}

private MySingletonClass() { }

...
}

It's got an if-statement in there, but for some reason, I like it this way


--
Gorf

[...]

Gorf> I do it a slightly different way, lazy instantiation...

Gorf> public class MySingletonClass {

Gorf> private static MySingletonClass instance;

Gorf> public static MySingletonClass getInstance() {
Gorf> if (instance == null)
Gorf> instance = new MySingletonClass();
Gorf> return instance;
Gorf> }

Gorf> private MySingletonClass() { }

Gorf> ...
Gorf> }

Gorf> It's got an if-statement in there, but for some reason,
Gorf> I like it this way

Lazy, but not threadsafe. You're much better off with Chris'
suggestion which is both.

--

- Keith James <> Microarray Facility, Team 65 -
- The Wellcome Trust Sanger Institute, Hinxton, Cambridge, UK -

Lance Lamboy wrote:

> I would recommend hiding accessing to the singleton through a public
> method. That way you preserve flexibility. You could update the
> previously mentioned MySingletonClass to the below code without anyone
> else having to change their code.

Ok. Thanks.

- Dario

Gorf wrote:
> I do it a slightly different way, lazy instantiation...
>

Here's probably more than you want to know...

The reason is rather subtle, but both of our pieces of code do lazy
instantiation. If I write:

public class MySingletonClass
{
private static MySingletonClass instance = new MySingletonClass();
...
}

That new object is created at class initialization time. In Java, class
initialization happens directly prior to the first access to the class,
and *not* at the beginning of the application.

Java is primarily designed that way because there's no way for the JVM
to know all the classes that will be used when the application first
begins -- as opposed to many other languages where an explicit link step
provides this information. In this case, though, we can take advantage
of this fact (which is specified, and therefore guaranteed) to delay
initialization of a singleton instance.

The primary advantage of the code as I wrote it above is that it is
implicitly thread-safe to retrieve the singleton instance. You could
provide this thread-safety explicitly in your version by synchronizing
the getInstance method, but there are several reasons it's at least
marginally better to go with class initialization:

1. The thread synchronization for class initialization is going to
happen anyway (to set your instance field to null, for example),
so you'd just be introducing redundant synchronization.

2. Synchronization can be done better by the JVM. It knows that
class initialization can only happen once, so it can (and almost
certainly does) actually mutate the code so that there is zero
cost for the synchronization after class initialization is
complete.

You may not be working in a multithreaded environment (although that's
hard to imagine in Java), or you might not be concerned about
performance, but when the better and faster technique is also easier to
read and write, it makes a good default to use that technique.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Keith James <> wrote in
news: .uk:

>
> Lazy, but not threadsafe. You're much better off with Chris'
> suggestion which is both.
>

Not to go off on a tangent, but I was reading about double check
locks recently. Does this make his example thread safe:

if (instance == null) {
synchronized(this) {
if(instance == null)
instance = new MySingletonClass();

}
}
return instance;