When Singleton should be used?
Singleton should be used incase creation of Object is costly or heavy I.E. DBConnection. It should not be used if the Object is mutable.

1. Eager initialization
2. Lazy initialization
3. Static block initialization
4. Using Synchronized method
5. Using Synchronized block
6. Double Checked Locking
7. Enum Singleton
8. Initialization on demand holder idiom

3 Things are common across all singleton implementation

private constructor
public static getInstance Method
private static instance field

Eager initialization
An instance of Singleton Class is created at the time of class loading

EagerInitialized.java

package com.mugil.singleton;

public class EagerInitialized {
	
	private static final EagerInitialized instance = new EagerInitialized();
	
	//Private Constructor
	private EagerInitialized()
	{
	}
	
	public static EagerInitialized getInstance()
	{
         return instance;
        }	
}

Lazy Initialization
With lazy initialization you crate instance only when its needed and not when the class is loaded

LazyInitialized.java

package com.mugil.singleton;

public class LazyInitialized 
{
	public static  LazyInitialized instance = null; 
	
	private LazyInitialized()
	{
		
	}
	
	public static LazyInitialized getInstance(){
        if(instance == null){
            instance = new LazyInitialized();
        }
        return instance;
    }
}

Static Block Initialization
Static block initialization is similar to eager initialization, except that an instance of class is created in the static block that provides an option for exception handling.

StaticBlockInitialized.java

package com.mugil.singleton;

public class StaticBlockInitialized {

	private static StaticBlockInitialized instance;

	private StaticBlockInitialized() {
	}

	// Static block initialization for exception handling
	static {
		try {
			instance = new StaticBlockInitialized();
		} catch (Exception e) {
			throw new RuntimeException("Exception occurred in creating singleton instance");
		}
	}

	public static StaticBlockInitialized getInstance() {
		return instance;
	}
}

Using Synchronized Method
The easier way to create a thread-safe singleton class is to make the access method synchronized, so that only one thread can execute this method at a time.

ThreadSafeSing.java

package com.mugil.singleton;

public class ThreadSafeSing {

    private static ThreadSafeSinginstance;
    
    private ThreadSafeSing(){}
    
    public static synchronized ThreadSafeSing getInstance(){
        if(instance == null){
            instance = new ThreadSafeSing();
        }
        return instance;
    }    
}

Using Synchronized Block
The easier way to create a thread-safe singleton class is to make the access method synchronized, so that only one thread can execute this method at a time. Refer the link for the same Link

ThreadSafeSing.java

package com.mugil.singleton;

public class ThreadSafeSing {
    private static ThreadSafeSinginstance;
    
    private ThreadSafeSing(){}
    
    public static ThreadSafeSing getInstance(){
        Synchronized(ThreadSafeSing.class){ 
          if(instance == null){
            instance = new ThreadSafeSing();
          }
        }
        return instance;
    }    
}

Double Checked Locking Singleton
Above Implementation of Singleton provides thread safety buy has a hit over performance. The performance hit happens when two threads try to get the instance of object in getInstance() method but only one is allowed within Synchronized block while the other needs to wait until the first is done checking irrespective of the instance is already created or not.

In the Below method of Implementing Singleton, we again use Synchronized Block but we do the check for the availability of the object instance even before taking lock.

DCCSingleton.java

package com.mugil.singleton;

public class DCCSingleton{

    private static DCCSingletoninstance;
    
    private DCCSingleton(){}
    
   public static DCCSingleton getInstanceUsingDoubleLocking()
   {
    if(instance == null){
        synchronized (DCCSingleton.class) {
            if(instance == null){
                instance = new DCCSingleton();
            }
        }
    }
    return instance;
  }    
}

Refer the Link for how Double Checked Locking works

ENUM Singleton
enum fields are compile time constants, but they are instances of their enum type. And, they’re constructed when the enum type is referenced for the first time.
ENUMSingleton.java
Simple Singleton using enum for DBConnection

public enum EnumSingleton
{
    INSTANCE;

    // instance vars, constructor
    private final Connection connection;

    private Singleton()
    {
        //Initialize the connection
        connection = DB.getConnection();
    }

    public Connection getConnection(){
       return connection;
    }

    // Static getter
    public static Singleton getInstance()
    {
        return INSTANCE;
    }
}

The way it works we can either use getInstance() method or directly call EnumSingleton.INSTANCE to access connection Object.

The Connection can be created using the Below Code

  Connection Conn = Singleton.getInstance().getConnection();

Minimal Implementation using ENUM

public enum MySingleton {
  INSTANCE;   
}

In the above code we may get a doubt how the object is created as we have a empty private constructor which is never invoked?.

The above code gets converted as one below. Above code has an implicit empty constructor. Lets make it explicit instead,

public enum MySingleton {
    INSTANCE;
    private MySingleton() {
        System.out.println("Here");
    }
}

Now when we make a call as below the private constructor is invoked and object gets created

public static void main(String[] args) {
    System.out.println(MySingleton.INSTANCE);
}

Output

Here
INSTANCE

Initialization on demand holder idiom
How it works?

1. The Below implementation is a lazy loading and thread safe method of creating Singleton
2. On calling the getInstance() method the lazySingletonClass would be initialized which in turn makes the INSTANCE to be initialized.
3. Class initialization is inherently thread-safe and if you can have an object initialized on class initialization the object creation too are thread-safe.
4. Singleton instance variable will never be created and or initialized until getInstance() is invoked. And again since class initialization is thread-safe the instance variable of IntiailizationOnDemandClassholder will be loaded safely, once and is visible to all threads.

public class Singleton {
    private Singleton(){}

    public static class lazySingletonClass{
      private static final Singleton INSTANCE = new Singleton();
    }

    public Singleton getInstance(){
        return lazySingletonClass.INSTANCE;
    }
}

	When Object is Created	Thread Safe	Performance	Comments
Eager Initialization	Object Gets Created once the Class is Loaded	Yes	Bad	Object is created everytime when the class is accessed
Lazy Initialization	Object is Created once required	No		In lazy initialization you give a public API to get the instance. In multi-threaded environment it poses challenges to avoid unnecessary object creation
Static Block Initialization	Object is Created once Static Block is loaded	Yes	Bad	Not a good idea to load resources from static block as it causes performance hit during app startup
Synchronized Method	Object is Created once getInstance is called	Yes	Bad	Thread safety is guaranteed.Slow performance because of whole method locking is done
Synchronized Block	Object is Created once getInstance is called	No		Two singleton instances may be created when context switching happens after checking instance is null
Double Checked Locking	Object is Created once getInstance is called	Yes	Good	Instance check is done twice
Enum Implementation	Object Created using enum is referenced	Yes	Good
Initialization on demand holder idiom	Object Created when static class is initiazlied by calling getInstance method	Yes	Good	Class initialization is inherently thread-safe and if you can have an object initialized on class initialization the object creation too are thread-safe

Note
Dont be confused between Class Loading and Initialization. In the Initialization on demand holder method of singleton you can easily get confused as the static inner class wont be loaded when the outer class loads. The implementation relies on the fact that during initialization phase of execution within the Java Virtual Machine (JVM) as specified by the Java Language Specification (JLS) When the class Singleton is loaded by the JVM, the class goes through initialization. Since the class does not have any static variables to initialize, the initialization completes trivially. The static class definition lazySingletonClasswithin it is not initialized until the JVM determines that lazySingletonClassmust be executed. The static class lazySingletonClassis only executed when the static method getInstance is invoked on the class

The static class lazySingletonClass is only executed when the static method getInstance is invoked on the class Singleton , and the first time this happens the JVM will load and initialize the lazySingletonClass class. The initialization of the lazySingletonClassclass results in static variable INSTANCE being initialized by executing the (private) constructor for the outer class Something. Since the class initialization phase is guaranteed by the JLS to be sequential, i.e., non-concurrent, no further synchronization is required in the static getInstance method during loading and initialization