Design Patterns Revisited - Singletons, How Single They Are..

public class SingletonObj

should be

public class Singleton

Another solution would be to use enum as Joshua Bloch suggests in his book(Effective Java).

enum Singleton{
  /** single instance of this class */
  INSTANCE;

  /** a method */
  public void doSomething(){

  }
} 

@tranquiliser: no no no no and no.  This is double-checked locking and it is NOT thread-safe. Without a memory barrier formed by synchronization on the read of instance, the instructions can be reordered and cause all sorts of thread problems.  The badness that can occur will become more and more likely as we add cores.  Do not do this.  For more detail, read Bill Pugh's paper on why double-checked locking is broken.

Well, in your case you get a thread-safe code by declaring the getInstance() synchronized. That would turn your code into a useable example, no need for disclaimers.

Slava 

Sebastian,

How would you demonstrate the implementation of the use case for singleton without the GoF's pattern? Any code samples?

Regards,

Slava Imeshev

Cacheonix: Distributed Java Cache

@Peter yes, *if* you wrote your code with volatile (which you didn't) and *if* you are using jdk 1.5+ (which many aren't) then it will work.  But I think it's simpler to just say, DO NOT USE DOUBLE-CHECKED LOCKING and leave it at that.  In all cases, it is less code, simpler code, equally as thread-safe, and possibly better performance to use the initialize-on-demand-holder idiom (see many references above) if you need to lazily instantiate a singleton. 

Josh Bloch recommends using an enum now to hold a singleton but I don't like this in all cases.  My main beef is that some singletons are written with mutable state and I think it's morally wrong :) to mutate state in an enum instance.  So, if you are registering and de-registering stuff in your singleton instance, then I object to holding it in an enum.  But then, I reject the use of the singleton pattern at all. :)

@Slava,

take a Foo-object/component (whatever), and stress out:

- when singletons are useful

- why singleton is an anti pattern (today)

- why singletoness is not a concern of the object

- and thus: singletoness should be achieved by aspects or an di container (like spring)

for your sample, one could easily fire up a simple spring configuration, with <bean... singleton=true> and that's it code wise. Patterns are so much about concepts and less about code. Simple examples should be really sufficient. What's really important to other developers (and architects) are concepts, the "when" and some realworld usecases.

But that applies for all tutorials, blog posts and presentations: We have that many stuff out there, presenting yet another api for web/dataaccess/services/rest/.... But no one is really covering the hard part: What to choose, When to choos, What are real use cases, What are best practises, What are anti-patterns. That is information we really need and most authors are so ignorant of. It is really really hard work, much harder than writing another api-tutorial (which microsoft et al have been teaching us the last 20 years).

-Sebastian 

So,i've got a component, called Foo:

class Foo {

 private Foo() {..} //so ensure non-instantiatability (urgs, spelling) 

 ...

}

I want it to be a singleton, so fire up your spring config:

<bean id="foo" class="Foo" singleton="true"/> 

Next, take your application context and retrieve the singleton instance:

ApplicatonContext ctx; 

Foo alwaysTheSameInstance =  ctx.getBean("foo");

No cou can specifiy in your container, if you need singleton-per-thread, global singleton or instance per request (prototype mode, default). You can change that easily and of course, you can have more than one fully configured component of type "Foo", if you need (simply take another component's name). Of course this is not directly the singleton pattern, but that's not regarded as a pattern either.

Hi Alex,

I have one question about the initialize-on-demand-holder:

How can I lazy load an 'expensive' variable for several instances of the same class with this idiom?

For example you have

class Person {

List<Person> getDependencies() { /*expensive operation*/ return dependencies; }

}

Now I can have several instances of Person. It is easy with the dc-locking. But with the initialize-on-demand-holder idiom I see no way, because all instances will be forced to use the same variable for the 'dependencies'

Where is my mistake?

Peter.

My pet project is a pattern enforcing compiler (PEC):

http://pec.dev.java.net/nonav/compile/index.html

You can use the compiler to enforce patterns and also write your own patterns and have the compiler enforce these. 

How do you get context?[/quote]

Slava, as you would normaly in Spring framework: create from xml-config or by hard-coded configuration (object definition builder, etc...). That's not topic of this blog-entry and it's spring basics - so it's up to you to learn on spring if you want to know. As DI containers are pretty common and required for todays architectures, it's worth the price to learn. You should be able to learn the basics in a couple of hours. Spring is (in it's most basic form) very simple.

-Sebastian

Double-checked locking and the Singleton pattern

http://www.ibm.com/developerworks/java/library/j-dcl.html

Summary

In an effort to avoid costly synchronization in singletons, programmers, quite ingeniously, invented the double-checked locking idiom. Unfortunately, it was not until this idiom was in fairly wide use that it became apparent that it is not a safe programming construct due to the current memory model. Work is underway to redefine areas of the memory model that are weak. However, even under the newly proposed memory model, double-checked locking will not work. The best solution to this problem is to accept synchronization or use a static field.

[quote=mgaravaglia]the third one is not thread safe :)[/quote]

 You might be interested in this: http://www.ibm.com/developerworks/java/library/j-dcl.html

Double check locking idiom and problems associated with it! 

In general: if you think that this is thread-safe implementation of Singleton (and you must admit this is not the simplest one which can be met), you are wrong:

public static Singleton getInstance()
{
  if (instance == null)
  {
    synchronized(Singleton.class) {  //1
      if (instance == null)          //2
        instance = new Singleton();  //3
    }
  }
  return instance;
} 

 

We have to put pure double-checked locking to rest, really.

The simplest and the cheapest is just to declare getInstance synchronized instead of messing with double locking. The speed difference is negligible. I have run the following code and got 7s for 10,000,000 accesses for not synchronized (not safe but fastest) method and 9s for the safe synchronized. The difference is only 0.2mks/call:

   private static final int NUMBER_OF_GET_INSTANCE = 10000000;
   private static final int NUMBER_OF_THREADS = 
      Runtime.getRuntime().availableProcessors();

   public static class Singleton {

      private static Singleton INSTANCE = null;
      private int counter = 0;

      private Singleton() {
      }

      public static synchronized Singleton getInstance() {
         if (INSTANCE == null) {
            INSTANCE = new Singleton();
         }
         return INSTANCE;
      }

      public int getCounter() {
         return counter;
      }

      public synchronized void incrementCounter() {
         counter++;
      }
   }


   /**
    */
   public void testSingletonSpeed() throws InterruptedException {
      final long started = System.currentTimeMillis();
      final CountDownLatch startLatch = new CountDownLatch(1);
      final Thread[] threads = new Thread[NUMBER_OF_THREADS];
      for (int i = 0; i < NUMBER_OF_THREADS; i++) {
         final Thread th = makeAccessThread(startLatch, 
            NUMBER_OF_GET_INSTANCE);
         threads[i] = th;
         th.start();
      }
      startLatch.countDown();
      for (int i = 0; i < threads.length; i++) {
         threads[i].join();
      }
      final long totalTimeMillis = System.currentTimeMillis() - started;
      log.debug("time, ms: " + totalTimeMillis);
      log.debug("counter: " + Singleton.getInstance().getCounter());
   }


   private Thread makeAccessThread(final CountDownLatch startLatch, 
      final int numberOfGetInstance) {
      return threadFactory.newThread(new Runnable() {
         public void run() {
            try {
               startLatch.await();
               for (int j = 0; j < numberOfGetInstance; j++) {
                  Singleton.getInstance().incrementCounter();
               }
            } catch (InterruptedException e) {
               return;
            }
         }
      });
   }

 

Regards,

Slava Imeshev

Cacheonix: Distributed Java Cache