La declaración object: un singleton garantizado por el lenguaje

Casi todos los lenguajes de la familia de la JVM te obligan a construir el patrón singleton a mano: constructor privado, campo estático, comprobación de nulo y, a partir de ahí, una discusión interminable sobre doble comprobación con volatile, clases interiores que hacen de soporte y enumerados de un solo valor. Kotlin borra la discusión con una palabra clave. Una declaración object no es una clase de la que después sacas una instancia: es a la vez la declaración del tipo y la declaración de su única instancia, y la unicidad deja de ser un asunto de tu disciplina para convertirse en una propiedad que verifica la máquina virtual. Merece la pena mirar el código generado, porque de él se deducen las tres preguntas que casi nadie sabe responder: cuándo nace ese objeto, quién garantiza que nazca una sola vez, y qué se ve desde el otro lado de la frontera con Java.

Una palabra que declara tipo e instancia a la vez

Cuando escribes una declaración object, el nombre que eliges cumple dos papeles simultáneos: es el nombre de un tipo, utilizable en firmas y en comprobaciones is, y es también una expresión que designa la única instancia de ese tipo.

object Registro {
    private val destinos = mutableListOf<Destino>()

    var nivel: Nivel = Nivel.INFO

    init {
        destinos += ConsolaDestino()
    }

    fun log(mensaje: String) {
        if (nivel <= Nivel.INFO) destinos.forEach { it.escribe(mensaje) }
    }
}

En el sitio de uso, Registro.log("hola") no construye nada: navega hasta una instancia que ya existe. La equivalencia en Java es literal y conviene tenerla en la cabeza, porque explica todo lo demás:

public final class Registro {
    public static final Registro INSTANCE;
    private final List<Destino> destinos;
    private Nivel nivel;

    private Registro() {
        this.destinos = new ArrayList<Destino>();
        this.nivel = Nivel.INFO;
        this.destinos.add(new ConsolaDestino());
    }

    static { INSTANCE = new Registro(); }

    public final void log(String mensaje) { /* ... */ }
}

Tres detalles cargan con casi todo el peso conceptual. La clase es final, así que nadie puede heredar de tu singleton para colarte una segunda encarnación. El constructor es privado y no hay ninguna forma legítima de invocarlo, de modo que la unicidad no depende de que nadie se despiste. Y el estado no es estático: destinos y nivel son campos de instancia normales, alojados en el único objeto al que apunta INSTANCE. La única excepción son los const val, que sí se compilan como constantes estáticas y, además, se insertan literalmente en cada sitio de llamada.

Una declaración object puede heredar de una clase abierta e implementar tantas interfaces como quieras, y puede anidarse dentro de otra clase, en cuyo caso se traduce a una clase anidada estática. Esa doble capacidad es la que la distingue de un simple espacio de nombres de funciones: un singleton de Kotlin es un valor de pleno derecho, asignable a una variable del tipo de la interfaz que implementa y pasable como argumento.

object OrdenNatural : Comparator<String> {
    override fun compare(a: String, b: String) = a.compareTo(b)
}

class Indice {
    object Vacio                                   // clase anidada estatica
}

val comparadores: List<Comparator<String>> = listOf(OrdenNatural)

Lo que no puede una declaración object es lo que veremos al final: recibir argumentos.

El instante exacto en que nace, y por qué es seguro

La inicialización de un object en la JVM es perezosa, pero no por obra de Kotlin: es la semántica de inicialización de clases de la propia máquina virtual. El inicializador estático de una clase, el <clinit>, se ejecuta en el primer uso activo de esa clase, y leer el campo estático INSTANCE es exactamente uno de esos usos. Antes de la primera mención, tu singleton no ocupa ni un byte de heap.

flowchart TD
A[Primer acceso a Registro en cualquier hilo] --> B[La JVM resuelve y carga la clase]
B --> C[Se toma el cerrojo de inicializacion propio de esa clase]
C --> D[Se ejecuta clinit con new Registro y los bloques init]
D --> E[INSTANCE queda asignado y la clase pasa al estado inicializada]
E --> F[Se libera el cerrojo y se despiertan los hilos en espera]
F --> G[Todo hilo posterior ve la instancia completamente construida]
style D fill:#f9e2af,color:#11111b
style G fill:#a6e3a1,color:#11111b

La seguridad frente a hilos sale de ahí y solo de ahí. La especificación de la JVM obliga a serializar la inicialización de cada clase con un cerrojo propio: el primer hilo que llega la inicializa, el resto bloquea hasta que termina, y la salida de ese cerrojo establece una relación de precedencia que garantiza que todos vean los campos ya escritos. Es, palabra por palabra, el idioma clásico de la clase de soporte que se inicializa bajo demanda, salvo que aquí lo escribe el compilador y no puedes equivocarte al copiarlo.

Hay un corolario incómodo. Como el cerrojo es reentrante para el mismo hilo, un ciclo de inicialización no explota: se cuela. Si el init de Registro toca Config y el init de Config toca Registro, el segundo acceso encuentra la clase marcada como “en curso de inicialización por este hilo”, devuelve el INSTANCE a medio construir y tú lees campos con su valor por defecto, es decir, nulos en referencias declaradas como no nulas. Si el ciclo cruza dos hilos, ya no es un nulo sorpresa sino un interbloqueo real entre dos cerrojos de clase.

Hay además una asimetría fácil de pasar por alto y que se puede comprobar en cinco minutos: leer un const val declarado dentro del objeto no inicializa nada. Como es una constante de tiempo de compilación, su valor se inserta literalmente en el sitio de llamada y la clase ni siquiera necesita cargarse. Es una diferencia observable entre dos declaraciones que en el código fuente parecen iguales.

object Ajustes {
    const val VERSION = 7            // leerlo no carga ni inicializa la clase
    val cargado = calcularCaro()     // leerlo dispara la inicializacion entera
}

Fuera de la JVM el fondo se mantiene y cambia el mecanismo. En Kotlin/Native, con el modelo de memoria moderno, las declaraciones object son singletons globales compartidos entre hilos e inicializados de forma perezosa y segura en el primer acceso, sin nada parecido al viejo congelado de objetos; si de verdad quieres una instancia por hilo, lo pides explícitamente con @ThreadLocal. En Kotlin/JS el entorno es de un solo hilo y la pereza es lo único que queda del contrato. Conviene no dar por supuesto el momento exacto de la inicialización en código multiplataforma: lo que sí puedes dar por supuesto es que ocurrirá una vez y antes del primer uso.

Lo que un object no puede ser

Un object no tiene constructor, y esa ausencia no es un olvido: si pudiera recibir argumentos, alguien tendría que decidir cuáles, y esa decisión implicaría poder construirlo, lo que contradice la unicidad. La consecuencia práctica es dura y hay que asumirla: un singleton solo puede configurarse leyendo del ambiente, es decir, acoplándose a él.

Tampoco admite parámetros de tipo. Una declaración genérica exigiría una instancia por argumento de tipo, y solo hay una. El truco canónico para sortearlo está en la propia biblioteca estándar y merece estudiarse: como Nothing es subtipo de todo, un objeto que implementa List<Nothing> es asignable a List<T> para cualquier T, y por eso emptyList puede devolver siempre la misma instancia sin mentir al sistema de tipos.

private object ListaVacia : List<Nothing> {
    override val size: Int get() = 0
    override fun isEmpty(): Boolean = true
    override fun iterator(): Iterator<Nothing> = IteradorVacio
}

fun <T> vacia(): List<T> = ListaVacia   // seguro: Nothing es subtipo de T

Y hay una última restricción, más social que técnica: un object no admite herencia hacia abajo. Puede heredar, pero nadie puede heredar de él, porque la clase generada es final. Si alguna vez necesitas dos variantes del comportamiento, no hay refactorización local que te salve: hay que convertir el singleton en una clase normal y repartir sus usos.

INSTANCE visto desde el otro lado de la frontera

Todo lo anterior se vuelve tangible cuando alguien consume tu código desde Java, porque ahí el campo INSTANCE deja de ser un detalle del bytecode y se convierte en la firma que se escribe a mano.

Registro.INSTANCE.log("sin anotaciones queda asi");
Registro.log("con JvmStatic en el miembro queda asi");

object Registro {
    @JvmStatic
    fun log(mensaje: String) { /* ... */ }

    @JvmField
    val nombre: String = "raiz"

    private fun readResolve(): Any = Registro   // defensa ante deserializacion
}

La trampa de interoperabilidad que se cobra víctimas cada año es la última línea. La serialización de la JVM ignora los constructores privados y fabrica una instancia nueva al deserializar, con lo que tu singleton deja de serlo en silencio y las comparaciones por identidad empiezan a fallar en sitios remotos. Declarar un readResolve privado que devuelva la instancia canónica cierra el agujero. Es exactamente la razón histórica por la que se recomendaba implementar singletons como enumerados de un solo valor en Java: el enumerado tiene esa defensa incorporada en la plataforma.