Patrón Singleton: Ejemplos en Java, Python y TypeScript

Visión general

Tu aplicación acaba de abrir un segundo pool de conexiones a la base de datos y ahora cada consulta compite por la mitad de las conexiones. Ese es el problema que resuelve Singleton: algunos recursos deben existir exactamente una vez — un pool de conexiones, un lector de configuración, un logger — y el patrón Singleton garantiza esa instancia única más una forma controlada de acceder a ella.

El patrón viene de la Gang of Four (Design Patterns, 1994) y es el patrón creacional más usado — y más abusado — de todos. Esta página cubre las implementaciones que de verdad sobreviven en producción: inicialización lazy y eager, double-checked locking con volatile, el idiom de Bill Pugh, el enum singleton de Java, singletons a nivel de módulo en Python y Node, registros y la alternativa de inyección de dependencias que querrás para todo lo testeable.

Cuándo usarlo

Usa Singleton cuando se cumplan todas estas condiciones:

• Debe existir exactamente una instancia — un pool de conexiones, una caché en memoria, un gestor de configuración, una factoría de loggers.
• Varias instancias entrarían en conflicto o desperdiciarían recursos (un segundo pool duplica las conexiones a la base de datos).
• Quieres inicialización diferida para posponer una preparación costosa hasta el primer uso.

No lo uses cuando:

• El objeto guarda estado mutable de negocio — eso es estado global con pasos extra. Pásalo como parámetro.
• Necesitas datos por usuario o por petición — un singleton con estado por petición es una fuga de memoria.
• La testabilidad pesa más que la comodidad — prefiere la inyección de dependencias, que da la misma instancia única con un contrato explícito.

Solución

Java — las implementaciones que importan

Empieza con el enum singleton. Son tres líneas, es thread-safe por garantía de la JVM y es la única variante inmune a ataques de serialización y reflexión (recomendación de Joshua Bloch en Effective Java, ítem 3):

public enum Configuration {
    INSTANCE;

    private final Map<String, String> properties = loadProperties();

    public String get(String key) {
        return properties.get(key);
    }

    private Map<String, String> loadProperties() {
        return Map.of("env", System.getenv("APP_ENV"));
    }
}

// Uso — la misma instancia en todas partes, imposible de duplicar
String env = Configuration.INSTANCE.get("env");

Si no puedes usar un enum (necesitas herencia), el idiom del holder de Bill Pugh da lazy init sin coste de sincronización — la JVM solo carga la clase interna en el primer acceso:

public class ConnectionPool {
    private ConnectionPool() {
        // preparación costosa: abrir pool, enlazar sockets
    }

    private static class Holder {
        static final ConnectionPool INSTANCE = new ConnectionPool();
    }

    public static ConnectionPool getInstance() {
        return Holder.INSTANCE;
    }
}

Y si necesitas construcción condicional o configurable, el double-checked locking funciona — pero solo con volatile; sin él, un segundo hilo puede leer una instancia construida a medias:

public class CacheClient {
    private static volatile CacheClient instance;

    private CacheClient() {}

    public static CacheClient getInstance() {
        if (instance == null) {                     // camino rápido, sin lock
            synchronized (CacheClient.class) {
                if (instance == null) {             // segunda comprobación dentro del lock
                    instance = new CacheClient();
                }
            }
        }
        return instance;
    }
}

El synchronized getInstance() ingenuo que ves en tutoriales antiguos es correcto pero más lento — bloquea en cada llamada, no solo en la primera.

Python — prefiere el módulo, no __new__

El singleton clásico con __new__ tiene dos trampas que nadie te cuenta: __init__ se ejecuta de nuevo en cada llamada (reinicializando tu estado) y el check-then-act dentro de __new__ no es atómico — el GIL no te salva aquí; dos hilos pueden seguir compitiendo entre la comprobación de None y la asignación. Si insistes en __new__, protégelo con un lock:

import threading

class ConnectionPool:
    _instance = None
    _lock = threading.Lock()

    def __new__(cls):
        if cls._instance is None:
            with cls._lock:
                if cls._instance is None:
                    cls._instance = super().__new__(cls)
                    cls._instance._initialized = False
        return cls._instance

    def __init__(self):
        if self._initialized:
            return                          # no reejecutar la preparación
        self._pool = self._create_pool()
        self._initialized = True

El idiom más limpio de Python es el propio módulo: los módulos se importan una vez y se cachean en sys.modules, así que una instancia a nivel de módulo es un singleton gratis — thread-safe, lazy en la primera importación y el enfoque recomendado:

# connection_pool.py
import psycopg2.pool

pool = psycopg2.pool.ThreadedConnectionPool(
    minconn=2, maxconn=10,
    dsn="postgresql://user:pass@localhost/db",
)

# Todo importador recibe el mismo objeto:
from connection_pool import pool

TypeScript — constructores privados y registros

Un constructor privado bloquea new y un accesor estático controla la única instancia. Para cualquier cosa más allá del caso más simple, un registro con nombres es más útil — mapea claves a instancias, así que obtienes “una por nombre” (un Multiton, de hecho) más un hook de reset para tests:

class Registry {
  private static instances = new Map<string, unknown>();

  static get<T>(key: string, factory: () => T): T {
    if (!Registry.instances.has(key)) {
      Registry.instances.set(key, factory());
    }
    return Registry.instances.get(key) as T;
  }

  static reset(key: string): void {
    Registry.instances.delete(key);
  }
}

const pool = Registry.get('db-pool', () => createPool(config));
Registry.reset('db-pool'); // en tests, entre casos

Node.js también te da singletons gratis igual que Python: require/import cachea módulos, así que una instancia exportada la comparte todo importador.

Diagrama

Explicación

Toda implementación de Singleton responde las mismas tres preguntas:

• ¿Quién bloquea new? Un constructor privado (Java/TS), un enum o el sistema de módulos del lenguaje (Python/Node).
• ¿Cuándo se crea la instancia? Eager en la carga, o lazy en el primer acceso — lazy ahorra coste de arranque pero introduce el problema de thread-safety.
• ¿Quién impone la instancia única? La propia clase, un registro o el contenedor DI.

Sobre thread-safety: la carrera siempre está en la inicialización lazy. Dos hilos llegan a if (instance == null) a la vez, ambos construyen y el segundo sobrescribe al primero. synchronized lo arregla de forma ingenua; volatile + double-checked locking mantiene el camino rápido sin bloqueos; el idiom del holder lo delega a las garantías de carga de clases. En Java hay un detalle más sutil — sin volatile, un hilo puede ver una referencia no nula a un objeto cuyo constructor no ha terminado de escribir los campos, porque la JVM puede reordenar los pasos “reservar → construir → asignar”.

Variantes

Variante	Lazy	Thread-safe	Testeable	Cuándo gana
Estática eager	No	Sí	Pobre	Inicialización barata, siempre necesaria
Accesor sincronizado	Sí	Sí	Pobre	Simple, poco tráfico
Double-checked locking	Sí	Sí*	Pobre	Ruta caliente, Java/C# — necesita volatile
Holder de Bill Pugh	Sí	Sí	Pobre	Lazy init en Java, sin coste de lock
Enum singleton	No	Sí	Pobre	Java — sobrevive serialización y reflexión
A nivel de módulo	Sí	Sí	Pobre	Python, Node — idiomático, cero maquinaria
Registro / Multiton	Sí	Sí	Buena	Instancias con nombre, hooks de reset
Contenedor DI	Sí	Sí	Excelente	Todo lo que necesites mockear

*Solo con volatile; sin él el check-then-act sigue roto.

Singleton en tests — la parte que los tutoriales se saltan

Un singleton con getInstance() hace los tests dependientes del orden: lo que un test muta se filtra al siguiente. Tres salidas:

// 1. Registro con reset — limpiar entre tests
afterEach(() => Registry.reset('db-pool'));

// 2. Contenedor DI — vincular un mock para la corrida de tests
container.bind(IPool).to(MockPool).inSingletonScope();
const service = container.get(OrderService);

// 3. Inyección por constructor — pasar la instancia explícitamente
const service = new OrderService(pool); // pool es el singleton en prod, un fake en tests

La respuesta honesta es la opción 3. Si alguna parte del código podría necesitar una segunda implementación en tests, inyecta la dependencia y deja el singleton solo como vinculación de producción.

Serialización, reflexión y classloaders

Tres formas en que Singleton se rompe en silencio, todas reales:

• Serialización (Java): deserializar crea una instancia nueva aunque el constructor sea privado. Arréglalo con readResolve():

  protected Object readResolve() {
      return getInstance();
  }

  O usa un enum singleton, que lo resuelve automáticamente.
• Reflexión: setAccessible(true) puede llamar a tu constructor privado. Los enum singletons son inmunes — la JVM garantiza una única constante.
• Varios classloaders: en servidores de aplicaciones y sistemas de plugins, la misma clase cargada por dos classloaders produce dos “singletons”. Los sistemas de módulos (Python, Node) tienen el problema equivalente con copias duplicadas del paquete. Si ves dos instancias, es el primer sitio donde mirar — System.identityHashCode() o id() lo confirmarán.

Alternativas

Alternativa	Obtienes	Pierdes
Contenedor DI (Spring, ASP.NET, Nest)	Ciclo de vida singleton + testabilidad + contratos explícitos	Dependencia del framework
Sistema de módulos (Python, Node)	Singleton idiomático gratis	Difícil de cambiar en tests
Monostate	Estado compartido, múltiples instancias	Los mismos riesgos de estado global
Clase estática	Lo más simple posible	Sin polimorfismo, sin mocks, sin inyección

Singleton frente a clase estática merece una línea extra: un singleton es un objeto — puede implementar una interfaz, pasarse como parámetro y sustituirse en tests. Una clase estática no puede hacer nada de eso.

Lo que funciona

• Mantén el estado del singleton inmutable o de solo lectura tras inicializarlo — el estado global mutable es donde viven los bugs de verdad.
• En Java: enum o Bill Pugh primero; son correctos sin que tengas que demostrarlo.
• En Python/Node: usa el sistema de módulos; no reinventes getInstance().
• Deja por escrito cómo se testea — un reset() del registro o una vinculación DI — antes de que el primer compañero tropiece.
• Documenta qué posee el singleton (conexiones, caché) y cómo se libera al apagar.

Errores comunes

• Asumir que __new__ es thread-safe por el GIL — no lo es; usa un lock o inicialización a nivel de módulo.
• Olvidar que __init__ se reejecuta en cada llamada Singleton() en Python y reinicializa el estado.
• Double-checked locking sin volatile — parece correcto, falla en producción.
• Un singleton con datos por petición o por usuario — es una fuga de memoria disfrazada de patrón.
• Servicios de lógica de negocio como singletons — un UserService singleton es una bomba de acoplamiento; inyéctalo.
• Saltarse el cierre — los pools y ejecutores fugan si nadie llama a close() al salir.

Lectura adicional

• Recursos complementarios — las implementaciones ejecutables en Python, Java y TypeScript de esta página.
• Singleton — refactoring.guru — explicación canónica del GoF con UML.
• Effective Java — Joshua Bloch — ítem 3 sobre el enum singleton.
• Singletons are Pathological Liars — Google Testing Blog — el argumento de testabilidad.
• synchronized y el modelo de memoria de Java — JLS §17 — por qué volatile es obligatorio en DCL.