El patrón de diseño Singleton asegura que una clase tenga solo una instancia y proporciona un punto de acceso global a esta. A continuación, exploraremos diversas implementaciones comunes de este patrón.

1. Inicialización Temprana (Eager Initialization)

En este enfoque, la instancia de la clase se crea en el momento de la declaración, es decir, cuando la clase es cargada por el cargador de clases (class loader) de la JVM.

public class ServicioUnico {
    private static ServicioUnico unicaInstancia = new ServicioUnico();

    public static ServicioUnico obtenerInstancia() {
        return unicaInstancia;
    }

    private ServicioUnico() {}
}

Ventajas: Es intrínsecamente seguro para hilos y la implementación es sencilla.

Aunque algunos cuestionan este método por no soportar la carga perezosa (lazy loading), especialmente si la inicialización es costosa en recursos o tiempo (por ejemplo, al cargar configuraciones complejas o consumir mucha memoria), lo que podría parecer un desperdicio si la instancia nunca se utiliza. Sin embargo, existe una perspectiva que valora esta inicialización temprana. Si el proceso de inicialización es largo, ejecutarlo al inicio del programa previene retrasos durante la ejecución principal, como en la respuesta a solicitudes de clientes, mejorando así la latencia del sistema.

Además, siguiendo el principio fail-fast (fallar rápido), si la creación de la instancia requiere muchos recursos, es preferible que cualquier problema de asignación de recursos se manifieste durante el arranque de la aplicación. Esto permite identificar y solucionar errores de forma inmediata, evitando que el sistema falle inesperadamente después de un período de operación.

Un ejemplo clásico de este patrón en el JDK de Java es la clase Runtime.

2. Inicialización Perezosa Simple (Lazy Initialization)

Esta variante retrasa la creación de la instancia hasta que realmente se necesita, es decir, la primera vez que se solicita el objeto.

public class GestorRecursos {
    private static GestorRecursos instanciaActual;

    public static GestorRecursos obtenerInstancia() {
        if (instanciaActual == null) {
            instanciaActual = new GestorRecursos();
        }
        return instanciaActual;
    }

    private GestorRecursos() {}
}

Esta implementación es fácil de entender, pero presenta una desventaja significativa: no es segura para hilos. En un entorno multihilo, múltiples hilos podrían intentar crear la instancia simultáneamente, resultando en más de una instancia del Singleton.

Se puede asegurar la seguridad para hilos añadiendo el modificador synchronized al método obtenerInstancia(). Sin embargo, esto tiene un impacto negativo en el rendimiento, ya que cada llamada al método incurrirá en la sobrecarga de un bloqueo y desbloqueo, reduciendo la concurrencia. Esta solución solo es aceptable si la instancia se usa de manera esporádica; para un uso frecuente, la penalización de rendimiento es inaceptable.

3. Bloqueo de Doble Verificación (Double-Checked Locking - DCL)

El patrón DCL busca ofrecer tanto carga perezosa como seguridad para hilos, minimizando el impacto en el rendimiento.

public class ConfigGlobal {
    private static volatile ConfigGlobal instanciaUnica;

    public static ConfigGlobal obtenerInstancia() {
        if (instanciaUnica == null) { // Primera verificación
            synchronized (ConfigGlobal.class) {
                if (instanciaUnica == null) { // Segunda verificación
                    instanciaUnica = new ConfigGlobal();
                }
            }
        }
        return instanciaUnica;
    }

    private ConfigGlobal() {}
}

Ventajas: Soporta carga perezosa y permite un alto nivel de concurrencia después de la primera inicialización.

Para comprender por qué esta construcción es efectiva, consideremos dos puntos clave:

1. La estructura del doble chequeo: La primera comprobación if (instanciaUnica == null) se realiza sin bloqueo. Solo si la instancia es nula, se entra en el bloque sincronizado. Dentro del bloque sincronizado, se realiza una segunda comprobación. Esto es crucial porque si dos hilos pasan la primera verificación simultáneamente, solo uno podrá adquirir el bloqueo. El hilo que adquiere el bloqueo procederá a crear la instancia. Cuando el segundo hilo finalmente adquiere el bloqueo, la segunda verificación asegurará que no se cree una nueva instancia, ya que la primera ya lo habrá hecho. Una vez creada la instancia, la mayoría de las llamadas posteriores al método evitarán el bloque sincronizado, mejorando drásticamente el rendimiento en comparación con un método completamente sincronizado.
2. El uso de volatile: La palabra clave volatile es esencial aquí. La operación instanciaUnica = new ConfigGlobal() no es atómica. Internamente, se descompone en varios pasos: 1) asignar memoria para el objeto, 2) inicializar los campos del objeto y llamar al constructor, y 3) hacer que la variable instanciaUnica apunte a la ubicación de memoria asignada. La reordenación de instrucciones por parte del compilador o la CPU podría permitir que el paso 3 ocurra antes del paso 2. Sin volatile, un hilo podría ver instanciaUnica como no nula y acceder a un objeto que aún no ha sido completamente inicializado, lo que llevaría a errores. volatile prohíbe la reordenación de instrucciones, asegurando que los pasos se ejecuten en el orden previsto y que la inicialización del objeto sea visible atómicamente para todos los hilos una vez completada.

3.1 Optimización del DCL con una variable local

Para mejorar ligeramente el rendimiento, se puede usar una referencia local a la instancia, reduciendo el número de accesos a la variable volatile.

public class ConfigGlobalOptimizada {
    private static volatile ConfigGlobalOptimizada instanciaUnica;

    public static ConfigGlobalOptimizada obtenerInstancia() {
        ConfigGlobalOptimizada referenciaLocal = instanciaUnica; // (1)
        if (referenciaLocal == null) {
            synchronized (ConfigGlobalOptimizada.class) {
                referenciaLocal = instanciaUnica; // (2)
                if (referenciaLocal == null) {
                    referenciaLocal = new ConfigGlobalOptimizada();
                }
            }
        }
        return referenciaLocal; // (3)
    }

    private ConfigGlobalOptimizada() {}
}

El uso de referenciaLocal minimiza los accesos directos a la variable volatile instanciaUnica. Acceder a una variable volatile implica operaciones de memoria más costosas que acceder a una variable local. Con esta optimización:

• (1) Se accede a instanciaUnica una sola vez para la verificación inicial si no es nula.
• (2) Dentro del bloque sincronizado, la referencia local se actualiza para asegurarse de que cualquier cambio realizado por otro hilo antes de adquirir el bloqueo sea visible.
• (3) La referencia local se devuelve al final, evitando un segundo acceso a la variable volatile en el caso de que la instancia ya exista.

4. Clase Interna Estática (Static Inner Class)

Esta implementación combina la carga perezosa con la seguridad para hilos de una manera elegante y concisa.

public class RegistradorSistema {
    public static RegistradorSistema obtenerInstancia() {
        return ContenedorInstancia.INSTANCIA;
    }

    private static class ContenedorInstancia {
        public static final RegistradorSistema INSTANCIA = new RegistradorSistema();
    }

    private RegistradorSistema() {}
}

Ventajas: Código limpio, seguridad para hilos y carga perezosa.

El funcionamiento se basa en cómo la JVM maneja la carga de clases:

• Carga Perezosa: Cuando la clase RegistradorSistema se carga, la clase interna estática ContenedorInstancia no se carga ni se inicializa de inmediato. Solo se carga cuando se invoca explícitamente a RegistradorSistema.obtenerInstancia(), lo que accede al campo estático INSTANCIA de ContenedorInstancia. Esto asegura que la instancia del Singleton se cree solo cuando realmente se necesita.
• Seguridad para Hilos: La JVM garantiza que la inicialización de una clase es atómica y se sincroniza automáticamente durante el primer acceso. Cuando ContenedorInstancia se carga e inicializa, la creación de INSTANCIA es realizada por un solo hilo de forma segura, incluso en un entorno multihilo.

5. Enumeración (Enum Singleton)

Introducida en Java 5, la implementación Singleton mediante enumeraciones es la forma más sencilla, robusta y recomendada.

public enum GestorSesion {
    UNICA_INSTANCIA;
    
    // Métodos o propiedades del Singleton
    public void mostrarMensaje() {
        System.out.println("Gestionando la sesión.");
    }

    private GestorSesion() {} // El constructor es privado por defecto
}

Ventajas: Código extremadamente conciso, seguridad para hilos garantizada por la JVM y protección contra problemas de serialización/deserialización y la creación de múltiples instancias a través de reflexión.

La seguridad para hilos se garantiza porque cada miembro de una enumeración es intrínsecamente static final. La JVM se encarga de la inicialización segura de los miembros de la enumeración de forma atómica y sincronizada, sin necesidad de escribir código adicional para ello.

6. Consideraciones Finales

Las implementaciones de inicialización temprana, clase interna estática y enumeración son opciones robustas y preferibles en la mayoría de los escenarios. La inicialización temprana, aunque no es perezosa, permite detectar problemas de recursos o inicialización al inicio del servicio, lo cual es una ventaja para el principio fail-fast. Si la carga perezosa es un requisito estricto y el código conciso es importante, la clase interna estática es una excelente elección. Para la máxima simplicidad, robustez contra la serialización y la reflexión, y seguridad para hilos garantizada, la implementación con enumeraciones es la opción más sólida y recomendada en Java.