0

Recently I was in an interview and they asked me Java Singleton pattern. So I wrote down the code for the double-check locking mechanism which is as follows:

public class MultiThreadedSingleton {

private static volatile MultiThreadedSingleton instance;

private MultiThreadedSingleton() {

}

public static MultiThreadedSingleton getInstance() {
    if (instance == null) {
        synchronized (MultiThreadedSingleton.class) {
            if (instance == null) {
                instance = new MultiThreadedSingleton();
            }
        }
    }

    return instance;
}

}

The pattern was fine but the interviewer said that I don't need to do locking. Then he asked me to write eager initialization code to which he said that you don't need any synchronized block. Which is true.

Shouldn't choosing of Singleton pattern depend upon the situation? If initialization task is heavy, I can use multi-threaded lazy initialization but if the initialization is light, I can go for eager initialization. Any guess?

Thanks

user2430771
  • 1,326
  • 4
  • 17
  • 33
  • Yes, it's necessary.. multiple threads can pass the first `instance==null` check. Without the second check, there can be multiple calls to `new MultiThreadedSingleton()` – LWimsey Jun 24 '19 at 20:17
  • "[You] don't need to do locking" Is the interviewer alluding to the [lazy holder idiom](https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom)? Or just using a single-element enum, for that matter? – Andy Turner Jun 24 '19 at 20:20
  • The question is not necessarily about whether the initialization is "heavy." We use lazy initialization to solve _two_ problems. Problem (a): For a singleton that might be needed in multiple different places, lazy initialization is one way to ensure that no matter who needs it, no matter when they need it, it _will_ be initialized by the time they get their hands on it. Problem (b): For a singleton that is only needed under special circumstances that might not happen at all during any given execution of the process, lazy initialization avoids paying that "heavy" price when it's not needed. – Solomon Slow Jun 24 '19 at 20:36
  • @SolomonSlow, For a singleton that might be needed in multiple different places, eager initialization can ensure it will be initialized just as good, if not better, than lazy initialization – Sharon Ben Asher Jun 24 '19 at 21:00
  • @SharonBenAsher, Yes, That's why I said "_one_ way to ensure..." Some developers do use it for that reason, and they use it in systems where the object is virtually always going to be needed. In short, you can find lazy initialization in systems where it won't ever avert a "heavy" initialization. I'm not saying whether that's a good thing or a bad thing: Just saying that it's a _real_ thing. – Solomon Slow Jun 24 '19 at 21:55
  • @SolomonSlow, I beg to differ. eager initialization (`public static Singleton instance`) is *the* safest and clearest way to have one available instance of a singleton when it is referenced (well, unless one uses custom class loader, in which case lazy initialization will fail as well). this way relies on the language semantics and standard operation, as opposed to elaborate locking logic – Sharon Ben Asher Jun 25 '19 at 06:25
  • @SharonBenAsher, Yes, That's why I said, "not saying whether that's a good thing or a bad thing." I only wanted to inform the OP that when they are trying to understand why some other programmer used lazy initialization, there might be other reasons besides a desire to defer "heavy" work. Also, the OP can infer from your comments, that the other programmer--the one who wrote the lazy code--might not have fully grasped how Java orders static initializers. The other programmer might have come to Java from a language where static initializers can only have `const` values. – Solomon Slow Jun 25 '19 at 13:39
  • @all I feel I should've put the question as "Under what circumstance would I decide to what Singleton pattern to use". I can only think about the 'heaviness' during initialization. – user2430771 Jul 03 '19 at 00:02

0 Answers0