Singleton is the first pattern I learned when I am a fresh programmer, it is impressed to me at that time due to it is easy to learn. Years by years, I have learned many variances of this pattern through how to apply lazy loading the static instance to the thread-safe of initializing the static instance by using the two main streams of implementation:

Method 1:

public class SingletonEx {
    private static SingletonEx impl = null;
    private  SingletonEx() {
        ...
    }
    public static SingletonEx getInstance() {
          //another implementation to prevent
          //thread-safe problem is making the
          //synchronized keywork before this statement
          if (impl == null) {
              impl = new SingletonEx(); //lazy loading static instance impl
          }
          return impl;
     }
}

Method 2:

public class SingletonEx {
    private static SingletonEx impl = new SingletonEx();
    private SingletonEx() {
        ....
    }
    public static SingletonEx getInstance() {
        return impl;
    }
}

Some developers guys critize the method 1 is not thread-safe, even if we make it is thread-safe, it takes cost whenever we call getInstances method. But we have some other guys say that we only use when we need so method 2 takes cost when the program init Singleton instance. Some smarter guys say that we use method 1 or method 2 depend on context, ok it sounds better than option1 or 2 but it is not enough, it has some reasons:

Method 1:

You need lazy loading, it is ok but it seems fail in your arguments . You do not save any time using lazy loading at all, when you need the instance at first, you must create the instance, if the cost of creating instance too much it will pact the response time of program to user, so why do you create it in some time before, moreover you need to care the thread-safe problem while creating instance,
Moreover, it is not a must in design pattern but singleton objects in most cases are called many times in your program (in my cases, this argument is all times). So creating it at first is a good choice for us.

Method 2:

As above arguments, you do not need to use lazy loading for singleton pattern and method 2 seems to be better, except you need consider the time of creating the singleton object, if the cost of creating is high you should consider loading it at the first of init program (warm up)

But, singleton pattern still be a dangerous pattern and is it really useful for architects. I think the answer is negative due to the following reasons:
1. It is not thread-safe in operation (most of developers care thread-safe while creating but not operating )
2. It does not abstract the implementation; it is harm when the singleton instance is not stable enough.
3. It makes the design not flexible, all are fixed with its implementation and it takes cost while refractoring.
4. It may lead the bottleneck on operations, and unexpected behaviors.

That makes me carefully when using singleton pattern, only when needed and think deeply its consequences when apply, some of experiences are:
1. Make only one singleton pattern in one place. That means you should not create many singleton objects in your design, but create one factory object (apply singleton pattern) and create singleton object through that object.
2. Only use operations in singleton object as read object (avoid thread safe problem). It is a good choice if we use it for cache mechanism.
3. Apply for stable classes that we make sure no change in future (of course, you do not know in future, but in current we must be sure it has no change) . Do you remember the impact when string class add more methods in java 1.4, what the hell of change impact.

Some developers guys critize the method 1 is not thread-safe, even if we make it is thread-safe, it takes cost whenever we call getInstances method. But we have some other guys say that we only use when we need so method 2 takes cost when the program init Singleton instance. Some smarter guys say that we use method 1 or method 2 depend on context, ok it sounds better than option1 or 2 but it is not enough, it has some reasons:

Method 1:

You need lazy loading, it is ok but it seems fail in your arguments . You do not save any time using lazy loading at all, when you need the instance at first, you must create the instance, if the cost of creating instance too much it will pact the response time of program to user, so why do you create it in some time before, moreover you need to care the thread-safe problem while creating instance.

Moreover, it is not a must in design pattern but singleton objects in most cases are called many times in your program (in my cases, this argument is all times). So creating it at first is a good choice for us.

Method 2:

As above arguments, you do not need to use lazy loading for singleton pattern and method 2 seems to be better, except you need consider the time of creating the singleton object, if the cost of creating is high you should consider loading it at the first of init program (warm up) But, singleton pattern still be a dangerous pattern and is it really useful for architects. I think the answer is negative due to the following reasons:
1. It is not thread-safe in operation (most of developers care thread-safe while creating but not operating )
2. It does not abstract the implementation; it is harm when the singleton instance is not stable enough.
3. It makes the design not flexible, all are fixed with its implementation and it takes cost while refractoring.
4. It may lead the bottleneck on operations, and unexpected behaviors. That makes me carefully when using singleton pattern, only when needed and think deeply its consequences when apply, some of experiences are:

• • Make only one singleton pattern in one place. That means you should not create many singleton objects in your design, but create one factory object (apply singleton pattern) and create singleton object through that object.
  • Only use operations in singleton object as read object (avoid thread safe problem). It is a good choice if we use it for cache mechanism.
  • Apply for stable classes that we make sure no change in future (of course, you do not know in future, but in current we must be sure it has no change) . Do you remember the impact when string class add more methods in java 1.4, what the hell of change impact.